ラベル Apple の投稿を表示しています。 すべての投稿を表示
ラベル Apple の投稿を表示しています。 すべての投稿を表示

2024年1月30日火曜日

Appleがアプリ規約を変えたのでApple IDに変わるIdPを考えてみる

こんにちは、富士榮です。

AppleがApp Storeの規約を変更したニュースが出ていますね。

https://gigazine.net/news/20240129-apple-sign-in-with-apple-remove/

元々はAppleがApp Storeの審査を行う上でソーシャルログインなど複数のIdentity Providerによるログイン機能を有するアプリにはApple IDでのログイン”も”サポートすることを要求していたのですが、今回の規約の改訂で以下の条件を満たすIdPをサポートすれば必ずしもApple IDとのID連携は行わなくても良い、という形に変更されました。

とはいえ、上記の記事にもある通り、以下の条件を満たすことのできるIdPってApple IDくらいしかないのでは?というなかなか厳しい状態です。

  • the login service limits data collection to the user’s name and email address
  • the login service allows users to keep their email address private as part of setting up their account
  • the login service does not track users as they interact with your app


ということは、APIでリレーエントリーを作成することができるリレーサービスがあれば実現できるのでは?と思い少し調べてみました。

触ってみたのはImprovmx(https://improvmx.com/ )というサービスです。※単純に検索して引っかかったので触ってみただけです。

APIドキュメントを見ているとどうやらAPI経由でエイリアスとなるメールアドレスから実際のメールアドレスへのリレーの定義ができるようです。

ということで触ってみます。

まずはベースとなるドメインの定義をします。

MXとTXTレコードの設定が求められるので、使うドメインのDNSサーバにレコードを作成し、ImprovMXのダッシュボードで確認を行います。

またAPIを実行するのでAPIキーの発行をしておきます。

API実行時はBasic認証でユーザ名に「api」、パスワードにAPIキーを設定してあげるだけです。

やりたいことはユーザがサインアップするときにランダムの仮名メールアドレスを発行し、実メールアドレスを隠した状態でアプリ側へ提供すること、アプリ側から仮名メールアドレスへのメールが送信されたときに実メールに対してリレーされることです。

そのためにAPIを使って仮名メールアドレスと実メールアドレスを紐づけるAliasを作成することができればOKです。

この辺りのAPIをつけば良さそうです。

https://improvmx.com/api/#alias-add

BodyにJSONでAliasとForwardを指定してPOSTするだけですね。


GET APIで設定状態の確認をすることができます。


無料版だと配送までに少し時間がかかりますが、「設定したAlias@設定したドメイン」に対してメールを送るとForwardに指定した実メールアドレスにメールが届きます。

このAPIコールをIdentity Providerの内部処理として組み込めばAppleが求めるIdPが実装できそうですね。

旧mac.comのApple IDもトラブルが出ているようですし、特定のIdPだけに頼らずにシステムを作っていけるようにしていきましょう。

2019年9月21日土曜日

iOS13でSign in with Appleがようやく使い物になってきた

こんにちは、富士榮です。

色々と騒動もあってついつい忘れがちなSign in with Appleですが、先週iOS13が正式に出てきてようやく使い物になってきました。
iPhone11は・・・ボトムズですよね。買ってません。

Sign in with Appleとは

いわゆるAppleのOpenID Connect実装です。iPhoneやMacを持っている人は必ず持っているApple Idを使って自前WebサイトなどへOpenID Connectを使ってログイン出来るようになります。
6月のWWDCで発表されて結構盛り上がりました。と、どうじにOpenID Connectの実装内容についても色々と意見がついてプチ炎上?してました。最近まともになっているようですが。
私もAzure AD B2CやAuth0へ組み込んでみたりしました。

 Azure AD B2Cへの実装
  https://idmlab.eidentity.jp/2019/06/sign-in-with-appleid-ad-b2c.html
 Auth0への実装
  https://idmlab.eidentity.jp/2019/06/sign-in-with-appleidaasauth0.html

8月頭には idcon でSign in with Apple特集も開催され一瞬で定員をオーバーするなど、注目度も結構高かった記憶があります。

iOS13未満の環境での課題

Sign in with Appleが発表された当時、まだiOS13はβ版でしたので人柱になっている人たち以外の一般人はあまり恩恵を受けられませんでした。
と、言うのもSign in with Appleでログインを行う都度、メールアドレス+パスワードの入力に加えてiPhoneへワンタイムコードが飛んでくる、という実装で、せっかく同じApple IdでログインしているiPhoneやiPadでも再度認証が要求されていたためです。

こんなUXでした。

iOS13からのUX

OSに統合されたのでTouch IDやFace IDでそのままログイン出来るようになりました。
素晴らしい!


日本人はiPhoneが大好きなので各種WebサイトのSign in with Apple対応も今後進んでくると思います。(みんながiOS13以上になるのがいつか?という話はありますが)

2019年6月29日土曜日

Identiverse 2019参加メモ(Day4)

こんにちは、富士榮です。

いよいよ最終日です。
割と毎日みっちりとセッションを聞いたので、かなりの疲労度ですが何はともあれようやく最終日です。

初日から3日までの記録はこちらです。


本日は午前中にブレークアウトセッションやマスタークラス(ベンダーによる製品解説)があった後、お昼の時間帯にクロージングキーノートとして待ちに待ったSteve Wozniakの登場、というスケジュールです。

では、早速参加したセッションについてメモを記録しておきます。

◆ブレークアウトセッション・マスタークラス

  • Adventures in Self-Sovereign Identity: From Hyperledger Indy to W3C Verifiable Credentials by Workday
    • 実はDIFのメンバーになぜWorkdayがいるのか結構疑問だったので、このセッションには期待していました。結果非常に有益でした。
    • スピーカーはCSOの人で、ここ最近Self Sovereign Identityのリサーチを担当してきたとのこと
    • 昨年よりIBMと一緒にHyperledger IndyベースでPoCをやってきた
    • 本日はその結果をデモを交えて紹介してくれるとのこと
    • まずはお決まり通り、SSIで解決したいことの例
      • 成績の情報を大学が学生に付与
      • 学生は就職したい企業に成績情報を提示
      • 企業が内容の検証をする
    • このシナリオで確認に時間がかかったり、プライバシーの問題を抱えていたりする(例えば、2018年以降に卒業していることがわかれば良いので、実際の卒業年度がわかる必要がなかったり、成績の平均が3よりよければ良いので実際の細かい点数までは必要ないはず、という話。ゼロ知識証明ですね)
    • 昨年、IBM、Workday、Evernym、ATB Financialで実証実験を行った
    • 学生のシナリオ以外に、以下のシナリオを各役割を持って実行した(要はオンラインでのKYCと銀行口座の即時開設のシナリオです)
      • Workday:従業員証の発行
      • ADOT(アリゾナ州の交通局):免許証の発行
      • Evernym:Identity Walletの提供
      • ATB Financial:銀行口座の開設
      • IBM:Hyperledger周りのインフラの提供
    • 環境を設計するにあたり、色々と検討したこと(この辺りはかなり細かく資料では説明されていたので今後資料が公開されることがあれば是非見てみるべきだと思います。そのくらい参考になりました。写真は結構撮りましたが、今回はとりあえずのメモだけ記録しておきます)
      • 暗号アルゴリズムの選定
        • Ed25519:署名・署名検証に利用
        • Curve25519:Key Agreementに利用
      • 属性のブラインディング(匿名化)
      • ゼロ知識証明の利用
      • Walletとの接続の方式
      • Schemaの設計
      • Credentialsの設計
        • Pairwiseにできるかどうか、、など
    • デモ1
      • WorkDayに従業員がログイン、Walletを登録する(QR読み込み)
      • WorkDay側で従業員の証明情報(Verifiable Credentials)を発行すると、従業員のWalletにプッシュ通知がされ、Wallet上に情報が読み込まれる
      • ATB Onlineのサイトで口座開設プロセスをスタートすると、QRコードが表示されるため、Walletで読み込むと先に発行された従業員情報を送信して良いか確認が入り、利用者が送信する属性を選択して送信するとATB Online側の開設プロセスが始まる
      • ATB Online側の確認プロセスが終了すると、従業員のWalletに開設された口座番号の情報がプッシュ通知される
      • 従業員がATB Onlineへログインする際は、発行された口座番号をサブミットするとWalletへ通知がくるので、承認するとログインが完了する(パスワードを登録していないので、完全にパスワードレスでのログインが実行される)
    • デモ2
      • 郵便局で検証済みの住所情報をWalletへ発行する
      • アイスクリーム屋さんのキャンペーンサイトで特定の住所に住んでいることが確認できれば無料でアイスクリームがもらえるクーポンが発行される
      • 利用者がアイスクリーム屋さんのWebサイトに表示されるQRコードをWalletで読み取り、郵便局で発行された検証済み住所を提示するとクーポンのバーコードが発行される
    • これらのシナリオをHyperledgeIndyと、素のW3CのVerifiable Credentialsを使って検証をしてPros/Consを出してみた。
    • まずはHyperledgerIndy
      • Pros
        • デフォルトでPairwiseなDIDが発行されるのでVerifier(RP)側での名寄せの心配がない
        • ゼロ知識証明をサポートしている
        • エコシステムが存在する(Ledger、Wallet、プロトコル)
        • 相互運用性の実験を行うプロジェクト(Project Aries)も存在する
        • PIIはLedger上には載らない
      • Cons
        • 暗号が難しいのでプロにしか良さがわからない(顧客や監査人への説明が難しい)
        • プロジェクトが同時並行して動いているのでパーツ単位で成熟度が異なる
        • プロトコルがLedgerと密接に紐づいている(今の所)
    • 次にW3C Credentials
      • Pros
        • 暗号モデルがシンプル
        • 相互運用性が高い
        • Ledgerの種類に依存しない
        • PIIはLedger上には載らない
      • Cons
        • DIDがPairwiseではないため名寄せが出来てしまう(注釈:実装の仕方次第だと思いますが)
        • Verifiable Credentialsのフォーマットは標準化されているが、伝搬のためのプロトコルは標準化されていない
        • 標準が最終化されていない
        • 標準がオープンすぎる。JSON-LD vs JSON vs JWT
    • プロジェクトから学んだこと
      • W3Cの方が開発しやすい(開発者にとって開発しやすい)
      • 標準仕様を見て素で開発するか、OSSのプロジェクトを使って開発するか考えないといけない
      • 何よりもSovrin/HyperledgerIndyが動いた
        • PoCではRevocationのシナリオはやらなかったのでその部分は注意
    • このテクノロジーに感じるポテンシャル
      • パスワードレス・ログインにも使える(強固な認証をスケーラブルに実装できる可能性がある)
      • この方式が標準として普及していくといいかも(SAMLみたいに)
    • その他

  • Auth0 Masterclass: Identity and the Yellow Brick Road - The Last Few Steps Are Always the Hardest by Vittorio Bertocci
    • クロージング・キーノート前最後のセッションはやはりVittorioのセッションで締めておこうと思います。
    • どういう状態がID基盤の理想の状態なのか?
      • 色々なプロトコルのアプリケーションやAPIに対応している
      • 色々なプロトコルのデータソースやディレクトリに対応している
      • 色々なデバイス(ブラウザ、モバイル、デスクトップアプリ)に対応している
    • 多くの場合、暗黙の前提事項がある
      • Identity Provider
        • サポートされること
        • IDaaSが対応しているプロトコルの一つに対応している
        • 移行できること
      • 認証ロジック
        • 標準に置き換えが可能である
        • そのまま(Out-of-box)で使える
        • 過去のIDとクレデンシャルがそのまま使える
      • 認可
        • 見たものが全て、つまり今のままの権限を移行できる
    • 簡単に使えるのか、色々と出来るのか、という軸で4象限で表すと、壁に突き当たる
      • デプロイの壁(自前のデプロイの限界地点。スケーラビリティとか)
        • ゼロから作るよりはSDKを使った方が簡単になるが、出来ることは減る
        • SDKより製品を使えば簡単になるが、出来ることは更に減る
        • どんなに頑張っても自前でデプロイするには専業クラウドを超えられない地点がある(コストが無限にあれば別だが)
      • コードの壁(汎用サービスではどうしても実現できない限界地点)
        • SaaS(IDaaSを含む)を使えば簡単に使えるがカスタマイズの自由度はほとんどない
        • PaaSなどに落とし込んでいけばカスタマイズの自由度はある程度上がるが難しくなってくる
        • いずれは自前でコードを書かないとなんともならない限界点に突き当たる
    • この問題へのある程度の答えが拡張可能なIDaaSである
    • 順に導入時の課題へのAuth0での対応を見ていく
      • Identity Source
        • 標準でサポートしていないIdPとの接続
          • 最近リリース(ベータ)された汎用OIDC接続を使う
        • 標準に対応していないIdPとの接続(Apple IDとか)
          • Extensionで接続する
        • 移行できないDBとの接続
          • カスタムDB接続を使う(無理に移行せずに、一旦は繋いでしまって時期を待つ)
      • UXのカスタマイズ
        • https://flows.auth0.comで簡単に画面デザインが出来る
        • 会社名を入れて検索すると勝手に会社のロゴをとってきてセットしてくれたりする
      • ユーザーライフサイクル
        • Pre-Signup、Post-SignupのルールをJavaScriptで拡張できるので、例えばIdentity Verificationを挟んだり、と色々と出来る
        • 追加の属性を他のDBからとってきたりも可能
        • 同意をとったり、外部のページへ飛ばすことも可能

ちなみにTシャツとダイアグラムの書かれた画用紙を貰いました

◆クロージング・キーノート

いよいよクロージングです。会場となるBall Roomが開くのを大勢の参加者が扉の前に押し寄せて待っています。

開場とともに人の群が良い席を求めて雪崩れ込んでいくのは圧巻でした。やはり参加者の一番の期待はSteve Wozniakですね。あっという間に会場は満席に。最終日の最後のセッションまでこんなに熱気があるカンファレンスも滅多にないんじゃないでしょうか?

会場から開演まで20分程度の間があったのですが、その間Electricヴァイオリンのライブ演奏がステージでは行われていました。Mark Woodの使っているような楽器を使っていて非常にかっこよかったです。ちなみにElectricヴァイオリンってフレットが付いているギターとヴァイオリンの合いの子みたいなモデルと、フレットレスのヴァイオリンをそのまま電子楽器にしたモデルがあるのですが、今回の方は前者のモデルをお使いでした。私も最近ヴァイオリンを弾くので、久しぶりにMark Woodを聴きたくなりました&楽器が欲しくなりましたw

さて、ようやく開演です。

Andre DurandのリードでSteve Wozniakがステージに登場すると会場は大盛り上がりです。


ステージはAndreとSteveの対談形式なので、正直なところ話の内容は拾いきれていませんが、いちいちジョークを挟みながらAndreの色々な問いに答えていくので、会場は度々爆笑の渦、でした。(付いていけない部分が多々ありましたが。名刺でステーキを切った?エピソードとか)


細かい内容は動画が公開されれば皆さんでも見ることも可能だと思いますし、私も追いきれなかったのでその時に改めて確認しようと思いますが、何点か重要だな、と思った点のみを。(かつ聞き取れた部分)
  • 注目しているテクノロジーは?AIとか。
    • 我々は脳がどのようになっているのかも分かっていないし、記憶がどこにストアされているのかすらも分かっていない
    • そんな状態なので、AIはインテリジェンスを持っていないし、シンギュラリティにはなり得ない
    • Googleは人間よりも犬の画像を認識するのは得意かもしれないが、犬が何であるかを知っているわけではない
    • 人間の脳は機械よりも優れているので、まだ存在しないものを想像して創造することが大切
  • Appleの起こしたInnovationでもっとも大切だったものは
    • iPhoneではない
    • Appストアでサードパーティにマーケットを解放したことである
    • それがなければ今、我々はUberやLyftを使うことができていないはずである
  • Blockchainベースのアイデンティティについてどう思うか?
    • 我々の日々の行動を政府がトラッキング可能で利用可能な状態であること、に対して、ブロックチェーンを導入すればこれ以上データを取得されなくなる、というのはブロックチェーンを正当化する理由にはならないと思う



そして、来年の開催地は「デンバー」です!
非常に楽しみです!




ということで、4日間に渡ってお伝えしてきた日記もおしまいです。

ちなみに午後はペンタゴンの側のショッピングモールに行ってきました。屋上からペンタゴンが見えたので写真を撮りましたが上空から取らないとなんだかわかりませんね。。。


2019年6月18日火曜日

Sign In with Apple連携その後。続々とIDaaSと連携~Auth0編

こんにちは、富士榮です。

前回のポストでAzure AD B2CとのApple ID連携を紹介しましたが、その後も各社が情報を出してきているのでUpdateしておきます。
やっぱりApple ID強いですね。

各社公式記事


特にAuth0はカスタムコネクションではなく、ベータ版ながらもビルトインでの接続を早くも出してきています。

話は変わりますが、先日のAuth0のCEOのEuginioさんが来日された時に発表されたLINE Loginとの連携についても早くビルトインで繋げられるようになればいいですね。

現状LINE Login連携はカスタムコネクションで実装する必要があるので、今すぐつなぎたい人はこちらで。


と、話を元に戻します。
今回はAuth0のビルトインコネクションでのApple Id連携を試してみます。

◆コネクションの有効化~設定

ダッシュボードを開き、ConnectionsよりSocialを選ぶとApple[BETA]が出てきますので、このスイッチをONにします。

続いて、前回Azure AD B2Cに設定したのと同様にclient idなどのApple側の値を設定していきます。
設定するのは、
  • Client ID
  • Client Secret Signing Key
  • Apple Team ID
  • Key ID
  • 取得する属性(名前、メールアドレス)※要するにscopeにnameとemailがつきます(なんだかうまく動いていない気がします)
ポイントはAppleからダウンロードした秘密鍵を張り付けるだけでclient secretを自前で生成しなくて済むのが非常に便利です。




設定が終わってSAVEをするとTRYボタンが現れるので、クリックすると設定が上手く行っているか実際にログインして確認が出来ます。



「It Works!」が出ればOKです。

◆実際のアプリケーションに組み込む

Auth0のダッシュボードからアプリケーションを作成し、Connectionsタブを開くと先ほど設定したAppleが出てきますのでスイッチをONにします。※今回は昔作ったアプリケーションを流用していますので、アプリケーション名が変ですw


これで設定は終わりです。
実際のアプリケーションへアクセスするとAuth0のログイン画面が表示され、その中にAppleが出てくれば成功です。
※ちなみに上2つはカスタムコネクションで設定したLINE LoginとApple Id連携で、今回設定したApple Id連携は一番下のボタンです。


まだ属性の取得周りなど上手く動いていなさそうなところもありますが、今後ブラッシュアップされてくると思うので、期待しておきたいと思います。

2019年6月10日月曜日

Sign In with AppleとのID連携現状のまとめ&Azure AD B2C連携

こんにちは、富士榮です。

WWDC'19でSign In with Appleが発表されてから皆Apple IDに夢中※1ですね。まぁ、アプリのレビューガイドライン問題※2とか色々とありますが、日本人は不思議とiPhoneが大好きなので下手したらGoogleアカウントより普及してるのかもしれません。(パスワードを覚えているかどうかは別でしょうけど)

※1.今日(6/9)時点で私が把握しているSign In with Apple関係の記事


※2.問題の概要
「サードパーティログイン採用のアプリはSign In with Appleを使うことを義務付ける」というレビューガイドラインが出たこと。Apple曰く、Relyingパーティに一切の個人情報を提供せずに認証だけを行うことができるためプライバシーに考慮している、という言いっぷりですが、逆にAppleが誰がどのアプリにログインしているかを把握するってこと?という気持ち悪い感じになっています。また、アプリ開発者はSign In with Appleを実装しなきゃダメ、という変な強権発動も流石Apple、という感じです。(個人の感想)


とは言え、Sign In with Appleが世の中に出てきたのでとりあえず色々とつないでみたくなります。私もAzure AD B2CとAuth0にはとりあえず繋いでみました。

というわけで、今回はAzure AD B2Cとのつなぎ方を解説します。
(先に書いた英語版のblogの日本語訳です)

********************
WWDC'19でアップルが「Sign In with Apple」という機能を公表しました。このポストではこの新しい機能をどうやってAzure AD B2Cで使うかを説明したいと思います。もちろん、この機能をIdentity Experience Framework(カスタムポリシー)を使って構成することもできますが、今回はビルトインポリシーのOpenID Connect IdP連携の機能(Preview)を使って構成します。


最初にどのような動きになるのかビデオに撮ってみました。



前提事項

  • アップル開発者アカウント(最低1年のサブスクリプション契約が必要)
  • Azure Active Directory B2Cのテナント
  • Azure WebApps等のWebホスティングサービス(Metadataのアップロード用)

アップル開発者コンソールでクライアントを構成する

「Sign In with Apple」はOAuth/OpenID Connect的な仕組みを採用しています(完全にプロトコルに準拠している訳ではなさそうですが)。そのため、それらのプロトコルに慣れ親しんでいる方であれば、実装するのはそれほど難しい話ではありません。

アップル管理者コンソールでOAuth/OIDCのクライアントを作成することが出来ます。手順については先に紹介したOktaのブログを参考にしました。とても良いブログだと思います。
https://developer.okta.com/blog/2019/06/04/what-the-heck-is-sign-in-with-apple

構成するための手順は以下の通りです。
  1. Sign In with Appleを有効にしてApp Idを登録する
  2. Service Idを登録する(これがclient_idとして使われます)
    • ドメインの所有権を確認する
    • redirect_uriを構成する
  3. Sign In with Appleで利用する鍵を登録する
  4. 登録した鍵をダウンロードして署名付きJWTを作る(これがclient_secretとして使われます)

Azure AD B2C上のIdentity Providerを構成する

Azure AD B2CでIdentity Providerを構成する前に、Apple Idに関するディスカバリ・ドキュメント(metadata)を作っておく必要があります。なぜなら、Appleは現在のところmetadata(/.well-known/openid-configuration)を公開していないためです。

私はAzure WebApps上に作成したmetadataを公開しましたが、任意のWebサービスを使うことが可能です。

Azure AD B2CのビルトインのOpenID ConnectのIdPを構成する際、metadataには以下の情報を記載する必要があります。
  • Issuer
  • Authorization Endpoint
  • Token Endpoint
  • Jwks Endpoint
また、metadataを公開するURIは./well-known/openid-configurationで終わっている必要があります。

こちらが作成したmetadataです。

さて、これでAzure AD B2Cのコンソールからビルトインポリシーを構成する準備が整いました。

新しいIdentity Providerを追加する。

OpenID Connect(preview)を選択する


metadata uri、client_id、client_secretを設定する。


sub属性を必須とされている属性へマッピングします。現状、Appleは名前やメールアドレスをid_tokenの中に含めて返してこないのでsub(pairwiseな値)しか使えません。

作成したIdPを利用する様にUser Flow(ポリシー)を構成する

Azure AD B2Cのコンソールでの最後のステップはUser Flowを構成することです。今回はSign In and Sign Up(v2)のポリシーテンプレートでApple IdPを使う様にフローを構成しました。

アプリケーションへ渡すための属性フローを構成します。


これで設定はおしまいです。

Azure AD B2Cに登録したアプリケーションから作成したポリシーを指定してID連携をすればApple Idでのログインが出来るようになっているはずです。


********************

と、言うことでまずはAzure AD B2Cでの構成方法を紹介しましたが、Auth0など他のものへの組込みについても解説できればと思います。(既に他の方も紹介されていますが)