「Appleでサインイン」エクスペリエンスを強化する

「Appleでサインイン」エクスペリエンスを強化する

「Appleでサインイン」を利用して、Appで安全かつ高速な認証を実現させる方法をご覧ください。パスワードベースのアカウントをセキュアなシングルタップログインの認証にアップグレードする方法や、Appでのユーザーセッションの変更をシームレスに処理する方法を紹介します。また、Webや他のプラットフォームでも「Appleにサインイン」を利用することができるようになります。このセッションを最大限に活用するには、「Appleにサインイン」やREST APIに関する知識を習得しておくとよいでしょう。また、JavaScriptの基本的な知識を習得しておくこともお勧めします。

リソース
関連ビデオ

WWDC22
- パスキーについて
- 勤務先と学校でのAppleでサインインについて
WWDC20
- ワンタップでのアカウントセキュリティのアップグレード
- Appleでサインインの最大活用
ダウンロード

こんにちはアカウント体験チームに所属しているエンジニアのRamです今回は同僚のPatrickと一緒に Appの Appleでサインイン体験を向上させる方法についてお話します iOS13 でAppleでサインインが導入されてから迅速で簡単なアカウント設定とサインインが好評ですわずか数行のコードでフォームやパスワードのないワンタップでの迅速なアカウント設定が可能になりました AppleアカウントでサインインはユーザーのApple IDを保護するために使われている強力な2ファクタ認証で保護されていますユーザーとのコミュニケーションをとる必要がある場合 Appleでサインインを使えばすぐに使えるメールアドレスが入手できます追加認証は必要ありません Appleでサインインを使用することでそのユーザーが実在する人物かどうかの指標にもなり詐欺対策にもなります Appleでサインインすると勤務先と学校で使用されている管理対象のApple IDを含めあらゆる場所で利用できます勤務先と学校のアカウントと統合する方法について「勤務先と学校での Appleでサインインについて」をご覧くださいこのセッションでは Appleでサインインをより効率的にする方法についてご紹介します Appの既存の認証情報をチェックすることでアカウント重複の防止をする方法について説明します次に Apple ID認証情報について深く掘り下げ認証情報の変更をモニタリングしてアカウントの削除などのシナリオを処理する方法について説明しますそして最後に Patrickが Appleでサインインを Webやその他プラットフォームで統合する方法を説明しますさあはじめましょう Appleでサインインは従来のユーザー名とパスワードによる認証に代わる便利で安全ですがユーザーはパスワードでアンロックするアカウントを持っている可能性もありますもしユーザーが既にアカウントを持っている場合 Appのために2つ目のアカウントを作らないことが重要ですサインイン時に正しい判断をできるように導く方法を見ていきましょう
これは JuiceというサンプルAppで Appleでサインインを使いますこの動画の関連リンクにソースコードがあります
Juiceへのサインインは従来のメールアドレスとパスワードかAppleでサインインを使いますユーザーが認証情報をすでに持っている場合はアカウントへのサインインはあなたの手にかかっていますまず最初にパスワードの自動入力を実装し既存のパスワード認証情報をキーボードに表示するようにします
これによりユーザーはワンタップで認証情報を自動入力できます
またパスワードベースのアカウントをアップグレードするために Appleでサインインを使用するようユーザーを誘導しましょうアップグレードするとセキュリティが組み込まれたアカウントにすることができ記憶しなければならないパスワードが一つ減ることになりますこの実装はアカウント認証変更拡張子で行われます拡張機能ベースのAPIは Appleでサインインを使いサインイン方法をアップグレードするためのシームレスな体験をユーザーに提供します
ユーザーのアカウントに安全なアップグレードを提供するための詳細はドキュメント「Appleでサインインを最大限に活用する」および「ワンタップでできるアカウントの安全なアップグレード」をご覧ください
パスワードの自動入力を提供するだけでなく Appの起動と同時に既存の認証情報を提示することでさらに一歩踏み込むことができますこれによりユーザーはログイン画面に入る前に正しいアカウントでサインインすることができます Authentication Services APIはこのように実に柔軟です APIを使うとユーザーが Appleでサインインの認証情報を作成できるほかパスワードベースの認証情報を含む既存の認証情報を提示することも可能です
これを採用することは実に簡単ですこれを実現するためのコードをご覧くださいすでにAuthentication Services APIを使用している場合このコードはとても身近に感じられるはずです
まず ASAuthorizationControllerのインスタンスを作成し ASAuthorizationAppleIDProviderと ASAuthorizationPasswordProvider の両方を認証リクエスト配列に追加します次にデリゲートとインターフェイスの提示を行うオブジェクトを設定する必要がありますそして最後に認証コントローラで AvailableCredentials オプションを指定して performRequestsを呼び出しますこのオプションはiOS16に新たに追加されましたシステムに対してすぐに利用可能な認証情報のみが必要であることを伝えます App起動時の呼び出しを想定しています
以前のiOSバージョンに対応させたい場合 performRequestsを使うことができますこれを実行すると既存の認証情報のリストが表示されますユーザーは既存の Appleでサインインの認証情報または既存のパスワード認証情報から選択できますユーザーが認証情報を選択した後システムは ASAuthorizationController デリゲートに対して didCompleteWithAuthorizationを呼び出しますユーザーがAppleでサインインを選択した際は appleIDCredentialで続行しますユーザーがパスワードベースのアカウントを選んだ場合は passwordCredentialが返されますユーザーが既存の認証情報を持っていない場合 APIはユーザーに Appleでサインインのアカウントを作成するよう提示しません代わりに didCompleteWithErrorを呼び出しますこの場合は標準的なログインフローを表示する必要がありますちなみに同じAuthentication Services APIはパスキーについてもシームレスに動作しますパスワードに代わる次世代認証技術であるパスキーについて詳しく知りたい方は「パスキーについて」セッションをご覧くださいほんの数行のコードでサインインの体験をフルに活用できますこれでユーザーが正しいアカウントを選択でき重複してアカウントが作成されるのを防ぐことができます
次に Apple ID認証情報を深堀りしたいと思います
ご存知のように Appleでサインインを使い認証に成功した後に得られるレスポンスは ASAuthorizationAppleIDCredential オブジェクトです user fullName email realUserStatus identityToken authorizationCodeなどの値が含まれますそれぞれについて簡単に説明します userとは一意の永続的なIDです開発者チームのすべての Appに共通するIDです
システム内のユーザーを一意に識別するために使用します fullNameは必要な時だけ聞いてくださいリクエストされるとユーザーは任意の名前を共有できますユーザーとのコミュニケーションには emailをお勧めしますユーザーには 2つの選択肢があります 1つ目はApple IDに関連付けられたメールを共有することですもう一つは「メールを非公開」を使いますこれにより非公開のメールアドレスが作成されユーザーの受信トレイに転送されます双方向リレーで返信も可能です
どちらの選択肢を選んでもメールアドレスはAppleに事前に確認されすぐに使用できますまたすべてのアカウントに関連するメールアドレスがあるわけではないのでメールを要求しても値がないシナリオに対応できるように準備してください
RealUserStatusは信頼度の高い指標で、実在する人物かを示しますプライバシーに配慮しながらデバイス上の機械学習アカウント履歴ハードウェア認証を使用して計算されます実際のユーザーステータスは 3つのタイプがあります「Likely real」とはユーザーが実在する人物に見えるという意味です CAPTCHAのような追加の不正確認チェックをスキップするなどユーザーに最高の体験を提供しましょう「Unknown」とはシステムがユーザーを実在の人物か判断していないという意味です追加の検証手順を必要とする限られた情報のアカウントと同様に、ユーザーを信頼しましょうそのユーザーは実在する可能性があるので Appの利用をブロックしないでください
最後に「unsupported」とはシステムがこの判定を行うことができないことを意味します fullName email realUserStatus などのプロパティはアカウントが初めて作成されたときだけ返されることをここで触れておきます
そのためアカウントが作成されたことを確認できるまで fullName emailなどのプロパティを安全にキャッシュすることが必要です
identityTokenは Appサーバーが必要とするデータのほとんどを含む JSON Webトークンですこれは業界標準の認証アプローチです JSON WebトークンまたはJWTの3つから構成されます base-64 URL エンコードされたヘッダー base-64 URL エンコードされたペイロードおよび Appleによって署名されたサインです Appleの公開鍵で署名を検証し改ざんされていないことを確認する必要があります Apple IDサーバからの応答であることを確認しますまた同様に重要なのが Appサーバーがトークンの有無を確認することですペイロードをデコードしたら発行元が appleid.apple.comであるかオーディエンスフィールドが AppのバンドルIDか有効期限タイムスタンプが現在時刻よりも大きいことを確認してトークンが有効であることを確認しますサブジェクトはユーザーIDになりますもしあなたがリクエストした場合ユーザーのメールアドレスも含まれます realUserStatusも確認できます値は「unsupported」の場合は 0になります 1は「unknown」 2は「likely real」ですそして最後に nonceが認証リクエストの作成前に生成されたものと同じであることを確認します
nonceの詳細とリプレイ攻撃を軽減のため認証プロセスを安全にする方法については「Appleでサインインの最大活用」のセッションをご覧ください
AuthorizationCodeはリフレッシュトークンと引き換えにApple ID サーバーに提供できる短命で1回しか使用できないトークンです OAuth 2.0などのオープンスタンダードをすでに利用しているシステムであれば馴染みのある話かもしれませんリフレッシュトークンを生成するには auth/tokenエンドポイントにポストリクエストを送信する必要がありますクライアントIDとクライアントシークレットを受け取ったばかりの認証コードと共に渡しますクライアントシークレットの作成方法の詳細は Appleデベロッパのドキュメントで確認できますレスポンスでリフレッシュトークンアクセストークン新しいIDトークンを取得します先ほど受け取ったもの同様ですね期限切れのアクセストークンがある場合リフレッシュトークンを使って同じエンドポイントから新しいアクセストークンを取得できますまた同じリフレッシュトークンを無効になるまで使い続けることも可能ですリフレッシュトークンはトークン認証に失敗した時やユーザーのセッションに変更があった場合に無効となる可能性があります
ユーザーセッションといえば次に認証情報の状態に関する変更の処理とモニタリングについてお話します IDトークンの検証後 Appにはユーザーセッションを管理する責任があります
ユーザーセッションが変更されるシナリオはさまざまですユーザーが設定からAppの Apple IDの使用を停止したりデバイスからサインアウトした可能性もありますセッションの変更を柔軟に処理するために getCredentialState (forUserID:)を ASAuthorizationAppleID Providerで呼び出しますこのAPIは Appが起動したらすぐに呼び出すことが推奨されていますまたは状態を確認したい時に呼び出しますまたcredentialRevoked Notificationを監視して認証が無効になったらAppに通知されるようにします状態の変化を観察したら別のユーザーがサインインしていると考えるべきです現在のユーザーをAppからサインアウトさせます Appサーバーがある場合サーバ間通知に登録する必要がありますサーバーにはユーザーとアカウントについて重要なアップデートが届きます通知はAppのグループごとに送信されます以下のシナリオが想定されますユーザーがメール転送設定を無効または有効にしたときユーザーがAppで AppleIDの使用をやめたときまたはユーザーがAppleIDを永久的に削除したとき通知の受信を開始するにはまず AppleデベロッパポータルにエンドポイントURLを登録する必要がありますすべてのイベントは同じエンドポイントURLに届きますイベントは Appleによって署名された JSON Webトークンとして送信されますメール転送が無効になった場合 JWTのペイロードで email-disabledイベントを受信します
AppでAppleIDの使用をやめた場合 consent-revokedイベントを受信しますこのイベントが発生したらアクティブなユーザーセッションを無効化することが重要です
またユーザーがAppleIDを削除した場合は account-deleteのイベントを受信します繰り返しになりますがアクティブなユーザーセッションを無効にし更新してください
次はアカウント削除に焦点を当ててみましょうアカウントは私たちのアイデンティティの一部ですそのアカウントで個人的なデータ管理のため使われますアカウントを削除したい人がいるかもしれませんこれをサポートする必要があります
アカウントの削除方法を提供する必要がありあなたのApp内で削除方法を用意する必要があります削除のプロセス全体を管理することはあなたの責任です
ユーザー情報を保存している Appサーバーがある場合通常 Appがサーバーにユーザーアカウントの削除について通知します Appleでサインインを削除のプロセスに含めることができますこれは Appに関連付けられたアカウントを削除するためにサーバーが使用できる新しいREST エンドポイントを使い実行しますこのAPIを簡単に説明しますアカウントを削除するためにはそのユーザーに対して有効なリフレッシュトークンかアクセストークンが必要ですどちらのトークンも持っていない場合は auth/tokenエンドポイントを使用して生成できますどちらかのトークンを取得したら必要なパラメータを指定して auth/revoke エンドポイントを使用できますリフレッシュトークンを使用する場合はトークンタイプを REFRESH_TOKENに設定します
アクセストークンを使って削除する場合トークンタイプを ACCESS_TOKENに設定します応答が成功した場合トークンとユーザーのアクティブセッションが即座に無効になります
一度削除されるとユーザーがAppに戻り Appleでサインインを使用すると Appで最初にアカウントを作成したときと同様の体験をすることになります
それではサインアウトして同僚のPatrickに引き継ぎ Webやプラットフォームで Appleでサインインをどのように使うかについて説明してもらいます
ありがとう Ram Appleでサインインがすべてのプラットフォームでシームレスに機能することは多くの人々に愛されていますしかしそれだけでは終わりません Appleでサインインは Webや他のプラットフォームでもシームレスに機能します Appleでサインインの体験を向上させる方法についてお話します
先ほど Ramが紹介した Juiceという iOS Appがあります Webにも展開することでより多くのユーザーに Juiceを届けたいと思いますまず似たようなAppをグループ化する方法から説明します
ユーザー体験を効率化するために関連した Appをグループ化することをおすすめしています関連するAppをグループ化することでユーザーは一度の同意で Appに情報を共有することができます
例えば AppはiOSと macOSで利用可能ですがプラットフォームごとに異なるバンドルIDを使用しているかもしれませんこうしたAppのグループ化をおすすめします Appleでサインインを使用する場合プライマリAppとして設定したAppのアイコンが表示されます AppleでサインインをサポートするためにサービスIDを設定する方法を説明しますまず Appleデベロッパポータルにログインします「Certificates, Identifiers & Profiles」に移動します
Services IDsの隣にあるラジオボタンを選択し「Continue」をクリックします
サービスの説明を入力してください
サービスの一意な IDを入力してくださいそして「Continue」をクリックします
Sign in with Appleの横のチェックボックスをクリックし「Configure」をクリックします Web認証の設定の画面を表示します Primary App IDをドロップダウンメニューから選択します
次にAppleでサインインをサポートするために Webサイトが使用するドメインとサブドメインを入力します最後に Appleの認証成功後に AppやWebにリダイレクト URLを入力してください以上です Webサイトで AppleでサインインをサポートするためにサービスIDを設定しました WebサイトがAppleでサインインに対応しているとユーザーに示すためのボタンが必要です Appleはボタン画像を生成するために高度に設定可能なボタンAPIを提供しています
これを使えば AppやWebサイトでカスタマイズしたボタンを埋め込むことができます Apple JSでサインインはシンプルなJavascriptのフレームワークです Web上で簡単に統合できます AppやWebで Appleでサインイン JavaScript フレームワークを組み込むことから始めてくださいこのシンプルなAPIを利用することでユーザーを認証し DIV一つで作成できる Appleでサインインボタンのような様々なアセットを取得することができますまたボタンのプロパティを変更することで AppやWebに合わせてカスタマイズもできます
例えば現在のプロパティでは白い「Appleでサインイン」ボタンが表示されます境界線とデフォルトのコーナー半径で表示されます data-colorプロパティを変更することでボタンの背景色を変更することができますデータ型を「continue」に変更するとボタンのテキストが更新され次のように表示されます「Continue with Apple」
またロゴのみのボタンを作成することもできますデータモードプロパティを「logo-only」に設定します Appleでサインイン JavascriptボタンAPIは他にもさまざまなプロパティを提供します Appleでサインインボタンについてのリソースを参照してさまざまなオプションを簡単に設定できます
REST APIを使用して Appleでサインインのボタンを生成したい場合は Apple IDボタンのエンドポイントの1つを使用してボタンを生成できます中央揃え左揃えロゴボタン用にそれぞれのエンドポイントが用意されていますクエリパラメータを使用してボタンをカスタマイズできますこの例のリクエストでは白い Appleでサインイン境界線ボタンをカスタマイズしています応答ではカスタマイズボタンを PNG画像として受信します Appleでサインインボタンをパーソナライズしたら次はユーザー認証です Appleに必要なパラメータを含む認証リクエストを送信する必要がありますこれらはユーザーのログインを成功させるために必要なパラメータです
すでにプラットフォームで Appleでサインインを実装しているためこれらのパラメータは非常に身近なものです
まずクライアントIDを設定しますこれがサービスIDになります Appleデベロッパポータルで作成したサービスIDとなります
次に AppやWebでメールや名前が必要な場合「scope」パラメータを書き込みます複数スコープを要求する時それぞれスペースで区切ります必要なデータのみを要求することが重要です
RedirectURIパラメータには Appleデベロッパポータルで事前に登録した URLを追加しますこれはあなたのどのWebサイトにユーザーを誘導すべきか Appleに通知します
「state」と「nonce」を追加してリクエストの安全性を確保することもできます
最後に「usePopup」パラメータでログイン画面を別のポップアップウインドウで表示するかまたは既存のウインドウで Appleサインインサイトにリダイレクトされます Safariを使用している場合このようなネイティブ画面が表示され Webサイトへの一流のサインイン体験をお届けします Apple IDサーバーが認証リクエストを処理した後認証結果を含む DOMイベントを受信します成功のレスポンスを処理するには "AppleIDSignInOnSuccess" のイベントリスナーを追加します
失敗のレスポンスを処理するには "AppleIDSignInOnFailure" のイベントリスナーを追加します
認証に成功すると認証コード IDトークンユーザ情報が含まれたレスポンスが返されますユーザー情報はリクエストされた場合のみ返されますこれは Appleのプラットフォームですでに慣れ親しんでいるレスポンスと同様です REST APIを使って Apple IDサーバと直接連携したい場合認証エンドポイントに必要なパラメータを指定して認証リクエストを送信してください認証に成功した場合認証コード IDトークンおよびユーザー情報を含む応答が得られますすでに慣れ親しんでいる Appleプラットフォームでの応答に非常に似ています以上です Webサイトに Appleでサインインを導入できました最後に Appleでサインインを導入する際に注意すべき点をいくつか挙げておきます
重要なアカウントベースの機能を必要とする Appでない限りログインを求めずにユーザーに提供しましょう例えば Apple Payで商品を購入した後にオプションとして購入した商品をアカウントに紐付けることをユーザーに提案することができます既存のユーザーに対してはユーザー名とパスワードでの認証から Appleでサインインに切り替えてアカウントのセキュリティのアップグレードを提供しましょうユーザーを特定するための一意なIDが必要なら名前もメールアドレスも収集しないでくださいそれでも Appleでサインインでメールアドレスを収集する場合ユーザーの選択を尊重してください追加メールアドレスの催促は行わないでください
AppやWebなど利用可能なすべてのプラットフォームで Appleでサインインを実装することが重要ですユーザーは複数のプラットフォームを使用する可能性がありどこにいても Appleでサインインを期待します Appleでサインインを使いどんなことができるのか皆さんのフィードバックをお待ちしていますご視聴有難うございました WWDCの続きをお楽しみ下さい

// Requesting both Sign in with Apple and password-based accounts.

import AuthenticationServices

let controller = ASAuthorizationController(authorizationRequests: [
    ASAuthorizationAppleIDProvider().createRequest(),
    ASAuthorizationPasswordProvider().createRequest()
])

controller.delegate = self
controller.presentationContextProvider = self

if #available(iOS 16.0, *) {
    controller.performRequests(options: .preferImmediatelyAvailableCredentials)
} else {
    controller.performRequests()
}

5:14 - ASAuthorizationControllerDelegate Implementation

// ASAuthorizationControllerDelegate

func authorizationController(controller: ASAuthorizationController,
                             didCompleteWithAuthorization authorization: ASAuthorization) {
    switch authorization.credential {  
		case let appleIDCredential as ASAuthorizationAppleIDCredential:
        // Sign the user in with Apple ID credential.
        // ...

    case let passwordCredential as ASPasswordCredential:
       // Sign the user in with password credential
       // ...
   }
}

func authorizationController(controller: ASAuthorizationController, 
   didCompleteWithError error: Error) {
    // No credential found. Fall back to login UI.
}

12:00 - Checking Credential State

// Check User Credentials on app launch

let appleIDProvider = ASAuthorizationAppleIDProvider()
appleIDProvider.getCredentialState(forUserID: "currentUserIdentifier") 
{ (credentialState, error) in
    switch(credentialState){
    case .authorized:
        // Found valid Apple ID credential
    case .revoked:
        // Apple ID credential revoked. Log the user out.
    case .notFound:
        // No credential found. Show login UI.
    case .transferred:
        // Team is transferred
    }
}

12:18 - Register for Revocation Notification

// Register for revocation notification

let notificationName = ASAuthorizationAppleIDProvider.credentialRevokedNotification

NotificationCenter.default.addObserver(self, 
                                       selector: #selector(signOut(_:)),
                                       name: notificationName, 
                                       object: nil)

17:55 - Sample HTML and Javascript Implementation

// Embed Sign in with Apple JS
<html>
    <body>
        <script type="text/javascript" src="https://appleid.cdn-apple.com/appleauth/static/jsapi/appleid/1/en_US/appleid.auth.js"></script>
        <div id="appleid-signin" data-color="white" data-border="true" data-type="sign in"/>
        <script type="text/javascript">
            AppleID.auth.init({
                clientId : '[CLIENT_ID]',
                scope : '[SCOPES]',
                redirectURI : '[REDIRECT_URI]',
                state : '[STATE]',
                nonce : '[NONCE]',
                usePopup : true
            });
        </script>
    </body>
</html>

18:28 - White Sign in with Apple Button

<div id="appleid-signin" data-color="white" data-border="true" data-type="sign in"/>

18:38 - Black Sign in with Apple Button

<div id="appleid-signin" data-color="black" data-border="true" data-type="sign in"/>

18:44 - Black Continue with Apple Button

<div id="appleid-signin" data-color="black" data-border="true" data-type="continue"/>

18:50 - Black Logo Only Button

<div id="appleid-signin" data-color="black" data-border="true" data-mode="logo-only"/>

19:47 - Sample HTML and Javascript Implementation

// Embed Sign in with Apple JS
<html>
    <body>
        <script type="text/javascript" src="https://appleid.cdn-apple.com/appleauth/static/jsapi/appleid/1/en_US/appleid.auth.js"></script>
        <div id="appleid-signin" data-color="white" data-border="true" data-type="sign in"/>
        <script type="text/javascript">
            AppleID.auth.init({
                clientId : '[CLIENT_ID]',
                scope : '[SCOPES]',
                redirectURI : '[REDIRECT_URI]',
                state : '[STATE]',
                nonce : '[NONCE]',
                usePopup : true
            });
        </script>
    </body>
</html>

21:11 - Handle DOM Response

// Listen for authorization success.
document.addEventListener('AppleIDSignInOnSuccess', (event) => {
    // Handle successful response.
    console.log(event.detail.data);
});

// Listen for authorization failures.
document.addEventListener('AppleIDSignInOnFailure', (event) => {
     // Handle error.
     console.log(event.detail.error);
});

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC22

WWDC20