Appleでサインインの最大活用

Appleでサインインの最大活用

Appleでサインインを使用すると、ユーザーは既に持っているApple IDでAppやWebサイトに簡単にサインインできるようになります。安全なリクエストを使用し、状態変更とサーバ通知を管理することで、AppleでサインインをAppに完全に組み込みましょう。ここではさらに、既存のユーザーがすばやく簡単にAppleでサインインに切り替えることを可能にする新しいAPIをご紹介します。

リソース
関連ビデオ

WWDC22
- 「Appleでサインイン」エクスペリエンスを強化する
- 勤務先と学校でのAppleでサインインについて
WWDC21
- アカウント、プロモーション、およびコンテンツの保護
WWDC20
- どこにでもAutoFill
- ワンタップでのアカウントセキュリティのアップグレード
WWDC19
- Appleでサインインの紹介
ダウンロード

こんにちは　WWDCへようこそ “Appleでサインインの最大活用” “Appleでサインインの最大活用” セッションへようこそアルフォンゾです今日はジョナサンと一緒に― Appleでサインインで新たに導入した項目について話しますこの機能を使えばアプリケーションに素早く簡単にサインインできますパスワードも不要なのでユーザーには使いやすいと好評ですユーザーの半数以上がプライベートメールリレーサービスを利用しています Appleでサインインでは― ワンタップでアプリケーションを使いアカウントを作成できるようになりました昨年のWWDCのセッション “Introducing Sign in with Apple”では― この機能をアプリケーションに追加する方法をお見せしています今日はいくつかのトピックがあります最初は認可リクエストとその安全性を高める方法です次はアプリケーションで資格情報の状態が変わった際のベストプラクティスデベロッパ向けの新しいサーバ間通知に関してや― Appleでサインインボタンの追加と変更についても触れます最後は Appleでサインインへのアップグレードについて説明しますユーザーにとってセキュリティは重要ですこれはAppleでサインインの開発でも重視した点です Appleでサインインでは― すでに自動２ファクタ認証などのセキュリティ機能を提供していますしかしリクエストをより安全にする方法があるのです認可リクエストを作成するためのベストプラクティスを紹介し― セキュリティ機能を最大限に活用する方法についても話します
これはSwiftを使い認可リクエストを作成する方法の例です Appleでサインインを実装したことがあれば見覚えがあるはず
AppleのButtonPressでサインインを処理するメソッドで― 認可リクエストとコントローラをここに用意します
リクエストのプロパティを変更し requestedScopesなどを追加できます名前やメールアドレスなどユーザー情報が必要な場合に有効です
認証プロセスをより安全にするのに役立ついくつかのプロパティがあります “nonce”と“state”です
これらのプロパティによりリクエスト実行後に取得する認証とその情報が期待どおりかを確認できますこのプロパティについて話しましょう nonceはリクエストで文字列として送信されるデータの不透明なblobです新規リクエストの作成のたびに固有のnonceを１つ生成しておけば― 後ほどこの値を確認できるようになります
nonceの値は認証情報のidentityTokenのプロパティに埋め込まれ返されます
するとサーバでこの値を確認でき反射攻撃を防ぐことができます
nonceと同様 stateの値もリクエストで送信されたデータのblobです nonceの値との大きな違いは１つ stateが資格情報内で返されると― 資格情報とリクエストをローカルで照合しアプリケーションから生成されたか確認できますこの追加プロパティにより― ユーザーにリクエストを提示するようコントローラに要求する準備ができます
ユーザーはこのような認可リクエストを目にしますメールアドレスがリクエストされた場合― メールアドレスを共有するか非表示にするか選択を求められますメールアドレスを非表示にすると― プライベートメールリレーを受け取りますここで疑問も出るでしょう “プライベートメールリレーとは？” “メールアドレスの確認方法は？” “ユーザーからの返信が必要な場合は？” その答えを見ていきましょう
メールリレーはメールアドレスと同様 Team scopeです開発者固有のものですが― ユーザーに見えるメールアドレスはすべてのアプリケーションで共通となります
メールリレーは― ユーザーの所有だとAppleが確認したアドレスにメールをルーティングしますつまりメールアドレスの確認については心配無用なのです
また必要な場合にはユーザーはメールに返信できますダウンタイムはないので電子メールの送受信はいつでもできますご覧のとおりメールリレーはユーザーにとって優れた選択肢であり― ユーザーと開発者の快適なコミュニケーションを維持しますプライベートメールリレーを使うユーザーの選択を尊重しましょうユーザーが選択をすると認証が進められます認証が成功すると認可コントローラのデリゲートメソッドで資格情報を受け取りますこれはauthorizationから資格情報を取得する方法の例です表示された資格情報には― 名前やメールアドレスなどユーザー情報を含むプロパティが見られます
これに加えリクエストを安全に検証しサーバとのセッションを作成できる― 重要なプロパティもあります stateとidentityTokenと authorizationCodeです名前やメールアドレスなどパラメータのいくつかは― アプリケーションを初めて認証した時にのみ資格情報に含まれます
必要なオブジェクトをキャッシュにすることが重要です接続不良でサーバとの通信が切断されることもありますが重要な情報の損失を防ぐことができます
資格情報のstateの値は前の値と同じかを確認してください
前述のとおり応答にはauthorizationCodeと identityTokenが含まれていますこれらの値をサーバに送信しデコードできるようにしましょう
デコードしたら受信情報と Appleサーバとのセッションを確認しますサーバでデコードされたidentityTokenがどうなるか見ましょう取得できる値はご覧のとおりです “sub”は― authorization内で返されたユーザー識別子ですこれでサーバ内でセッションを作成できます “nonce”は前述のとおりとても重要な値ですリクエスト以前に生成したnonceと同じものかは確認してくださいこれによりauthorizationの信頼性を確認し反射攻撃を軽減できます
メールアドレスを要求した場合は identityTokenにも含まれます
“real_user_status”はユーザーがアプリケーションを認証した時に返されます未サポートは“０” 不明の場合“１” リアルであれば“２”と出ます identityTokenは JSON Web Tokenであり― authorizationに関連するいくつかの情報が含まれています
その情報を得た段階で― Appleで入手できるパブリックキーを使いトークンを検証しますトークンの有効期限も確認しておきましょう
AppleIDサーバとauthorizationCodeを交換できたら― 今後の呼び出しのためリフレッシュトークンとアクセストークンを受け取りますすでに持っているものと同一のIDトークンも受け取ります
リフレッシュトークンは１日に１回確認すれば― デバイス上のApple IDが良好な状態かを確かめられますベストプラクティスに従えばスムーズなサインインを提供できるだけでなく中に含まれるauthorizationや情報が有効かつ安全であることを確かめられます認証プロセスを説明したので― アプリケーションの資格情報の状態を確認する際のベストプラクティスも見ましょうここで使うのが “getCredentialState”APIです格納されているユーザー識別子を送信して資格情報の現在の状態を検証し― ユーザーがこのデバイスとアプリケーションにサインインしているか確認できるAPIですセッションを続行して問題ないか確かめるのに役立ちます起動時やフォアグラウンドで変更がある時に呼び出すことが重要ですステータスの変化にリアルタイムで反応し― アプリケーションの適切な画面をユーザーに提示できます
このAPIを呼び出し受け取ることのできる既知のstateですもう一度それぞれのケースについて何をすべきか見てみましょう
“authorized”となっていればユーザーのアプリケーションを直接追跡できログインUIはスキップできます
“revoked”はユーザーのサインアウトを意味しますこの場合はユーザーをアプリケーションからサインアウトさせ― セッションを閉じログイン画面を表示します “notFound”はユーザーIDと一致する資格情報がない場合に返されますログイン画面を表示しユーザーがアプリケーションを認証できるようにします最後に新しいstateがあるのが見えるでしょうか “transferred”ですこのcredentialStateの処理方法について話しておきましょう
Transferred credentialStateは― 開発チーム間で直近に転送されたアプリケーションでだけ受信が可能です会社が買収された後などに使われます
ユーザー識別子はチームに固有のものですアプリケーションの所有権を譲渡する際は― 新たなチームと一致させるため別のIDに移行する必要があります
移行はユーザーの操作なしで静かに処理されます新規アカウント作成やユーザーのログインの際と同じAPIを呼び出せば実行されますご覧のとおり新旧のアカウントのコードは同一のものです
現在格納されているユーザー識別子をリクエストに追加することで― ユーザーの転送状態を検証できますそして新チームと一致する新たなユーザー識別子を生成します
応答はAuthorizationControllerのデリゲートメソッドで返されますユーザーは変更に気づくことなくアプリケーションを引き続き使用できます Appleでサインインに今年導入した新機能についても話しましょうまずは開発者向けサーバ間通知です通知によりcredentialStateの変更などをサーバで直接確認できます他のイベントと同じように通知されます通知の受信を開始するプロセスは簡単ですまずApple Developerのサイトでサーバのエンドポイントを登録すると― イベントの通知の受信を開始する準備が整います
イベントはAppleが署名した JSON Web Tokenとして送信されますトークンがどう見えるかを説明します JSON Web Tokenには重要な情報が含まれています発行者やアプリケーションのバンドルIDなどですこれは“email disabled”イベントの例で― ユーザーがメールリレーでのメール受信を停止すると決定した場合に取得されます
“email enabled”イベントはユーザーがメール受信を選択したことを意味しますこのイベントはemail disabledと同様で― プライベートメールリレーを使用するとユーザーが決定した場合にのみ送信されます “consent revoked”イベントは― ユーザーがアプリケーションでのApple IDの使用の停止を決めた時に送信されますユーザーのサインアウトとして扱う必要がありますこの通知を受け取る可能性があるのが― 設定からユーザーがアプリケーションを切り離すと決めた時です “account delete”イベントは― ユーザーがAppleに IDの削除を要求した時に送信されますこの通知を受け取ると― ユーザーに関連づけられたユーザー識別子は無効になりますこのとおりこれらの通知を開くことで― ４つの異なるシナリオに対してサーバから適切な対処ができるのですそれでは別の新機能についてもお話ししましょう SwiftUIのAppleでサインインボタンです SwiftUIを使えばAppleでサインインボタンを簡単に表示できますそれだけでなく SwiftUI APIは認可リクエストの作成にも役立ちます同じコードブロック内での応答の処理も同様ですご覧のとおりボタンの作成は非常に簡単です SignInWithAppleButtonオブジェクトを追加しラベルを指定するだけですここでは“signIn”を選択しましたが― “Continue”や“SignUp”を選択することもできますその後にはリクエストを作成できる “onRequest”クロージャがあります以前 Swiftで見たように― 名前やメールアドレスのような “requestedScopes”を追加できます nonceやstateの値も同様ですボタンには “onCompletion”クロージャもありますリクエストの結果を取得し成功や失敗のケースを処理する場所ですが― これは認可コントローラのデリゲートメソッドと同じですボタンのスタイルを選択することもできます Appleでサインインボタンに使用できるスタイルは― ブラックかホワイトかホワイトアウトラインですボタンのスタイルをパーソナライズしたい場合もあるでしょう特定のWebサイトやアプリケーションのデザインに合わせたいようなら― それが可能な新しいオンラインポータルをご紹介しますサイトへのアクセスは appleid.apple.com/signinwithapple/button へここではボタンの機能もカスタマイズできますラベルやサイズやポジションもですボタンアセットをダウンロードし― プロジェクトやサイトにインポートもできますではジョナサンに Appleでサインインへのアップグレードについて話してもらいますありがとうアルフォンゾ昨年発表したAppleでサインインは大反響を呼びましたワンタップでアプリケーションにサインインできる点がとても好評ですしかし従来のユーザー名とパスワードベースのアカウントを使っていて― 現アカウントをフォークしたくないユーザーには？今年は新しいAPIを導入し― Appleでサインインへのアップグレードを促しますユーザーのアカウントを Appleでサインインに更新させると― まず開発者とユーザーの両方にとって安全です Appleでサインインへの更新はアカウントを２ファクタ認証にする最も簡単な方法です Appleでサインインは２つの要素を求め― ローカルの資格情報の状態にデバイストラストを利用しますアカウントの回復も Appleでサインインで簡単になりますユーザーはよくパスワードを忘れ照合が必要になりますが― あなたがユーザーの秘密を管理する必要はなく Appleでサインインを代わりに行いますこのAPIを利用すればアカウントの重複も防げますこの機能の利便性とセキュリティをユーザーは気に入るはずです従来のユーザー名とパスワードベースのアカウントを持つユーザーも― 現アカウントを放棄する必要がなくなりましたアップグレードすればいいからです “Appleでサインインにアップグレード”は新しいAPIで― ユーザーにとっては高速で簡単なセキュリティアップグレードですあなたのアプリケーションを含む iOSとiPadOS全体の多くの場所で利用可能ですユーザーをアップグレードさせるために― AuthenticationServicesは拡張ベースのAPIを利用していますこの拡張機能をアカウント認証変更拡張と呼びますユーザーにシームレスな体験を提供し― Appleでサインインへサインイン方法をアップグレードできますユーザーが Appleでサインインにアップグレードすると― フローが正常に完了した時弱い資格情報がシステムから削除されます独自のUIを追加するためのサポートもあり― Appleでサインイン資格情報を聞く前にセキュリティ検証を完了させたい場合に使えます強力なパスワードへのアップグレードも同時にサポートされます今回はAppleでサインインへのアップグレードのフローを説明します新しいAPIの実装や強力なパスワードへのアップグレードに関する詳細は― “One-Tap Account Security Upgrades”のセッションをご覧ください実装後ユーザーが拡張機能を呼び出す方法は３つあります１つは設定の新しいパスワードマネージャでセキュリティ勧告が弱い資格を特定した時です２つ目はユーザーがアプリケーション操作でパスワードの自動入力を利用し― 弱い資格を選択した時です
最後はあなたがアプリケーション内でユーザー操作を指定し AuthenticationServices APIを呼び出した時です次は呼び出された拡張機能がどう機能するか見てみましょうアカウント変更拡張にはいくつかの概念があります名前で分かるでしょうが― ASAccountAuthenticationModification ViewControllerはビューコントローラですサブクラスは NSExtensionPrincipalClassです
拡張機能への最初の呼び出しが非ユーザーインタラクティブ関数を呼び出し― 既存の資格でのAppleでサインインへのアップグレードを促す最初の試みとなりますここでアップグレードが行われれば― ユーザーにとって最小限の作業で済みます
ユーザーの検証に追加のUIが要る場合を考えステップアップセキュリティビューを表示し― 同じ資格情報を個別に定義された関数を介し拡張機能にパスすることもできます
最後の要素は拡張コンテキストプロパティです拡張コンテキストは拡張と拡張のホスティングプロセスの通信に使用されますユーザー対話型およびステップアップセキュリティの機能内でです拡張コンテキストにより― 拡張ホスティングプロセスに起きたこと起きるべきことを伝えられます
これはExtensionViewControllerサブクラスのスタブアウトバージョンで― 名前はAccountModificationViewController ご覧のとおり３つの関数をオーバーライドしています convertAccountToSignInWithApple WithoutUserInteractionは― 拡張ホスティングプロセスによって呼び出されましたユーザー操作なしで資格をアップグレードしようとしたのです２つ目はviewDidLoad 必要に応じて中間UIのセットアップに使用できます進行状況を示す中間UIの提供は― ネットワーク呼び出しや遅延が発生する場合ユーザーエクスペリエンス向上に役立ちます最後のprepareInterfaceToConvertAccount ToSignInWithAppleは― ビューが表示される直前に呼び出されます非ユーザーインタラクティブフローで提供される同じASPasswordCredentialを通過しますこの資格情報はフォームにユーザー名を事前入力するなどのアクションに使われますまたは２ファクタ認証フローを開始します時間がかかるタスクは非同期で実行し― 中間UIを利用して進行状況を示すべきですこの呼び出しが終了するまでステップアップビューは表示されません AccountAuthentication ModificationViewControllerの概要は以上ですすべてがどのように連携するか― ASAccountAuthenticationModification ExtensionContextを見てみましょう拡張コンテキストはアカウント変更ビューコントローラの不可欠なプロパティです前述のように拡張コンテキストはアップグレードのフローを制御しますフローをどう制御するのでしょう？まずApple認証でサインインを要求する機能がありますリクエストの呼び出しに近く― アルフォンゾが述べたように Apple ID資格情報を使用しますアプリケーション固有のサインインUIが表示されます
資格情報やサインイン中のアカウントを審査し― アカウント検証のために追加のUIが要ると判断した場合拡張コンテキストはStepUpSecurityUIの表示を要求するために使われます
ホスティングプロセスにフローの完了を指示するのにも使われ― これにより既存の資格情報が削除されます最後にフローを完全にキャンセルする必要がある場合にも使われます
拡張コンテキストプロパティをさらに詳しく見てみましょう getSignInWithAppleAuthorization WithStateは― サインインUIとアプリケーションの情報を表示しユーザーにアップグレードの承認を求めます先ほどアルフォンゾが― ASAuthorizationAppleIDリクエストの stateとnonceを説明しましたアップグレードフローではnonceとstateはこの呼び出しへのパラメータとしてパスされますユーザーがアップグレードを承認すると完了ハンドラが呼び出され― フローの完了後 Apple ID資格情報を使用します次はcompleteUpgradeToSignInWithApple これは拡張ホスティングプロセスに認証が正常に完了したことを知らせ― パスワード資格情報を削除させます
最後はcancelRequest
APIはこれがASExtensionErrorと共に呼び出されることを想定しています拡張機能が追加のUIを表示する必要があると決めた場合― これをuserInteractionRequiredエラーで呼び出すことが重要ですユーザーがUIフロー内でキャンセルした場合は userCanceledエラーを利用します他のすべての失敗は failedエラーを使用できます前のスライドではアカウント変更ビューコントローラの概要を解説しました次に拡張コンテキストプロパティがどうフローを制御するか見ました今度はUIなしでアカウントを変換する実装の詳細を見てみましょう OSでフローを始めますユーザーが弱い資格情報で操作し― その資格情報をAppleでサインインにアップグレードしたい場合ですアカウント変更拡張がパスワード管理プロセスにより初期化されましたそしてConvertwithoutUI関数が呼び出され― Appleでサインインにアップグレードするためパスワード資格情報を提供します拡張機能の仕事は資格情報を審査し― それが有効かどうかをアップグレードする前に確認することですユーザー名がサインイン中のユーザーと一致するか確認するのが― 最初の適切なアクションです
拡張機能がユーザーの状態と資格情報から判断し― アカウント検証のためにサーバを呼び出すとしますサーバが資格情報を検証し認証は成功です次にサーバは拡張機能に返信し― アカウントをAppleでサインインにアップグレードする準備ができたと確認します
アカウントが認証されアップグレードできると確認されたので― 拡張コンテキストは Apple ID資格情報の要求に使われますそのフローの解説の前に― アカウントに問題がありすぐにアップグレードできない場合を見てみましょう
先ほどと同様フローの始まりはユーザーが弱い資格情報を使い― Appleでサインインにアップグレードを試みたところですアカウント変更拡張がパスワード管理プロセスにより初期化され― PreparetoConvertWithoutUI関数がパスワード資格情報と共に呼び出されます情報が拡張機能によって検証されます資格情報を検証するサンプルコードを見ましょうサンプルコードは列挙型を定義し検証結果を表しています検証結果を表す値は３つあります “success”“failure” “twoFactorAuthRequired”です
既存の資格情報が検証されると３つの値のどれかが返されます
“failure”と出るのはサーバによる資格情報の検証で― アカウントかサーバの状態がアカウントの変換に適さないとされた場合ですこの場合 extensionContextを使い cancelRequestを呼び出しフローは終了します
“success”はアカウントがすぐに変換できることを示しますシーケンス図で示したとおりです extensionContextを使い Apple ID資格情報を取得します
“twoFactorAuthRequired”はユーザーに UIを見せる必要があることを意味します資格情報だけではAppleでサインインにアップグレードできませんこれもextensionContextを使って処理され― userInteractionRequiredエラーで cancelWithErrorを呼び出します図に戻ります拡張機能が verifyCredential関数を呼び出すと― 拡張機能のバックエンドが呼び出され資格情報を検証しますサーバはリクエストを受けアカウントの確認を試みます
このアカウントに追加の検証が必要であると判断しました
その返事が拡張機能に戻り― verifyCredential関数が検証結果を “twoFactorAuthRequired”とします verifyCredential呼び出しのサンプルコードが示すようにこのケースは拡張コンテキストを使って処理され― userInteractionRequiredエラーで cancelWithErrorを呼び出しますユーザーに余分な作業をさせぬよう UIのリクエストは必要最低限にしましょう多くの場合ユーザーは Appですでに認証されていて― 非ユーザーインタラクティブのフローで変換を完了できますただしこの例に見られるように UIフローが保証される状況もありますどう機能するか見てみましょう userInteractionRequiredエラーで拡張コンテキストがキャンセルされた後― パスワード管理プロセスがアカウント変更ビューコントローラの新しいインスタンスを初期化 PreparetoConvertWithoutUI関数を呼び出し ASPasswordCredentialをパスします
拡張機能のビューコントローラが表示され― スピニングギアなどの中間UIを提供します前と同じ資格情報を利用しコンテキストを少し変更するだけで― バックエンドにリクエストが行われますサーバはアカウント検証を試み― ２ファクタ認証が必要だと拡張機能に返事を送ります拡張機能はビューを更新し２ファクタ認証をユーザーに要求ユーザーが検証コードを提供し拡張機能が検証しますここでユーザーを検証できなければ― 失敗エラーでフローをキャンセルするために拡張コンテキストが使用されますユーザーが有効なコードを提供し検証が成功すれば拡張機能はApple ID資格情報を要求できますこれでハッピーパスに戻りましたアカウントが認証されアップグレードの対象となりますアカウントは準備完了 Apple ID資格情報を要求しフローを終了しましょうアルフォンゾが言うようにリクエストの安全性は重要です拡張機能はstateとnonceを生成し― getAppleIDCredential呼び出しのパラメータとしてパスします AppleでサインインにアップグレードするUIがユーザーに表示され― ユーザーはFace IDを使って認証します getAppleIDCredential呼び出しの完了ブロックで Apple ID資格情報が拡張機能に提供され― 拡張機能は資格情報の状態プロパティを先ほどの例と同様に検証します拡張機能はアカウントのアップグレードを要求必要なアカウント情報とApple ID資格情報をサーバのバックエンドに提供し― アカウントを変換できるようにしますバックエンドは認証コードを Appleサーバと交換 identityTokenのnonceの値を検証し成功の場合アカウントの変換を実行し―
変換後成功値を含む応答を返しますサーバの操作が失敗した場合― 拡張コンテキストを使う必要があり失敗エラーでcancelWithErrorを呼び出します今回はサーバが成功を示しているので拡張機能は必要な記録を行い― 拡張コンテキストでcompleteUpgrade ToSignInWithAppleを呼び出しますパスワードマネージャが既存の資格情報を削除しフローは完成です新しい拡張機能はユーザーのセキュリティを向上させるためにあります弱い資格情報の代わりに Appleでサインインを提供するのです古い資格情報は削除するため次にサインインする時に混乱することはありませんこのAPIを利用すればユーザーに― 資格情報の最良のセキュリティプラクティスをアカウントの重複を避けつつ実装させられます便利なAPIでユーザーの既存アカウントを Appleでサインインに更新させましょう “Appleでサインインにアップグレード”を実装してもらい感想を頂くのが楽しみです楽しんでいただけたでしょうか引き続きWWDCをお楽しみください

// Configure request, setup delegates and perform authorization request

    @objc func handleAuthorizationButtonPress() {
        let request = ASAuthorizationAppleIDProvider().createRequest()
        request.requestedScopes = [.fullName, .email]
        
        request.nonce = myNonceString()
        request.state = myStateString()
            
        let controller = ASAuthorizationController(authorizationRequests: [request])
            
        controller.delegate = self
        controller.presentationContextProvider = self
            
        controller.performRequests()
    }

5:37 - Get a credential from an Authorization

// ASAuthorizationControllerDelegate

func authorizationController(controller: ASAuthorizationController, didCompleteWithAuthorization authorization: ASAuthorization) {
        if let credential = authorization.credential as? ASAuthorizationAppleIDCredential {
            let userIdentifier = credential.user
            let fullName = credential.fullName
            let email = credential.email
            let realUserStatus = credential.realUserStatus
            
            let state = credential.state
            let identityToken = credential.identityToken
            let authorizationCode = credential.authorizationCode
            
            // Securely store the userIdentifier locally
            self.saveUserIdentifier(userIdentifier)
            
            // Create a session with your server and verify the information
            self.createSession(identityToken: identityToken, authorizationCode: authorizationCode)
    }
}

8:51 - Verify the state of a credential

// Getting a credential state
        
        let provider = ASAuthorizationAppleIDProvider()
        
        provider.getCredentialState(forUserID: getStoredUserIdentifier()) { 
                                                        (credentialState, error) in
            switch(credentialState) {
            case .authorized:
                // Sign in with Apple credential Valid
            case .revoked:
                // Sign in with Apple credential Revoked, Sign out
            case .notFound:
                // Credential was not found, fallback to login screen
            case .transferred:
                // Application was recently transferred, refresh User Identifier
            @unknown default:
                break
            }
        }

11:00 - Migrate a user identifier

// Migrating a user identifier

        let request = ASAuthorizationAppleIDProvider().createRequest()
        request.requestedScopes = [.fullName, .email]
            
        request.user = getStoredUserIdentifier()
        
        request.nonce = myNonceString()
        request.state = myStateString()
            
        let controller = ASAuthorizationController(authorizationRequests: [request])
            
        controller.delegate = self
        controller.presentationContextProvider = self
            
        controller.performRequests()

13:54 - Create a Sign in with Apple button

// SwiftUI example:

SignInWithAppleButton(.signIn) {
    onRequest: { (request) in
        request.requestedScopes = [.fullName, .email]
        request.nonce = myNonceString()
        request.state = myStateString()
    }
    onCompletion: { (result) in
        switch result {
        case .success(let authorization):
            // Handle Authorization
        case .failure(let error)
            // Handle Failure
        }
    }
}.signInWithAppleButtonStyle(.black)

25:15 - convertAccountToSignInWithAppleWithoutUserInteraction

enum VerificationResult : Int { case success; case failure; case twoFactorAuthRequired;

override func convertAccountToSignInWithAppleWithoutUserInteraction(
    for serviceIdentifier: ASCredentialServiceIdentifier, 
    existingCredential: ASPasswordCredential
) {
    verifyCredential(existingCredential) { (result: VerificationResult) in
        switch result {
        case .failure:
            self.extensionContext.cancelRequest(withError: 
                ASExtensionError(.failed))
        case .success:
          self.extensionContext.getSignInWithAppleAuthorizationWithState(state: myStateString(),
                                                                         nonce: myNonceString(),      
                                                                         {…}        
        case .twoFactorAuthRequired:
            self.extensionContext.cancelRequest(withError: 
                ASExtensionError(.userInteractionRequired))
    }
}

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

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

リソース

関連ビデオ

WWDC22

WWDC21

WWDC20

WWDC19