WWDC Quick Look 💓 By SwiftGGTeam
One-tap account security upgrades

One-tap account security upgrades

元の動画を見る

ハイライト

iOS 14 のアカウント認証変更拡張機能を使用すると、システムのパスワード マネージャーとアプリ内設定ページで、ワンクリックで危険なパスワード アカウントを強力なパスワードにアップグレードしたり、Apple でサインインしたりでき、成功すると、iCloud キーチェーンの古い認証情報を更新または削除できます。

主要内容

パスワードが長期間再利用されると、多くのアカウントのリスクが表面化します。ログインもスムーズになり、他のサービスへの同じパスワードの漏洩も防げません。 iCloud キーチェーンはすでにパスワードを保存し、パスワードの自動入力を提供することができ、ユーザーの入力負担を軽減することもできます。 iOS 14 までに、システム パスワード マネージャーはユーザーに直接リスクを課し始めます。再利用され、推測されやすく、公的データ漏洩に登場するパスワードは、セキュリティ推奨事項に登録されます。

古いプロセスの問題は現実のものです。システムはユーザーを Web サイトのパスワード変更 URL に誘導できますが、ユーザーはページを開いてフォームを見つけ、古いパスワードを入力し、新しいパスワードを設定する必要があります。ジェイ・ムラーニ氏はスピーチの中で、ほとんどのユーザーはパスワードの変更が面倒に感じるため、変更を避けるだろうと直接指摘した。

Apple の変更は、「アカウントの修復」をシステム レベルのアップグレード アクションに変えることです。アカウント認証変更拡張機能は、ユーザーが脆弱なパスワードまたは漏洩したパスワードを使用してアプリケーションにログインした後、パスワードの詳細ページ、優先度の高いセキュリティ推奨事項、およびシステム プロンプトに表示されることがあります。拡張機能の実装では、iCloud キーチェーンによって生成された強力なパスワードに変更するか、Apple でサインインするようにアカウントをアップグレードするという 2 つのパスをサポートできます。

同じ機能セットをアプリ独自のアカウント設定ページに組み込むこともできます。アプリはアップグレード リクエストを作成し、拡張機能の完了後にシステムがキーチェーン認証情報を更新または削除します。ユーザーに表示されるのは短いプロセスです。開発者は、承認を拡張し、サーバー上でアカウントの変更を送信し、必要に応じて追加の検証インターフェイスを表示する責任があります。

詳細

アプリとサービスのドメイン名を関連付ける

(06:15) 拡張機能が iCloud キーチェーンのアカウントをアップグレードできるようにするには、アプリはまずサービス ドメイン名とのセキュリティ アソシエーションを確立する必要があります。このプロセスはパスワードの自動入力と同じです。サーバーは、ドメイン名とアプリの関係を宣言するための JSON ファイルを提供します。 Xcode は、関連付けられたドメイン機能をアプリに追加し、一致するドメイン名を書き込みます。

キーポイント:

  • JSON ファイルは、Web 認証情報サービスを使用して、ドメイン名とアプリを認証シナリオにバインドします。
  • 関連ドメインの資格は、このアプリが特定のドメイン名資格情報のアップグレードを提供できるかどうかをシステムが判断するための基礎となります。
  • 関連付けが完了すると、ユーザーの iCloud キーチェーンに保存され、サービスに属するパスワードがアップグレード ポータルに表示される可能性があります。
  • この事前手順は、システム パスワード マネージャーのアップグレード ボタンと、アプリケーション内でトリガーされるアップグレード プロセスの両方に影響します。

強力なパスワードのアップグレードをサポート

(07:17) 強力なパスワードのアップグレードは、新しいアカウント認証変更拡張ターゲットから始まります。拡張テンプレートは、デフォルトで 2 種類のアップグレードをサポートすることを宣言します。強力なパスワードのみをサポートしたい場合は、拡張機能の Info.plist に強力なパスワード変更サポート項目を保持する必要があります。

(08:23) ユーザーがログイン後にパスワード マネージャーまたはシステム プロンプトから強力なパスワードのアップグレードをトリガーすると、システムは拡張機能を起動し、既存の資格情報、サービス ID、およびシステムによって生成された新しい強力なパスワードを拡張機能に渡します。システムによって開始されたリクエストでは、userInfo常に空です。

キーポイント:

  • 拡張機能のビュー コントローラー サブクラスはビジネス ロジックのエントリ ポイントであり、バックエンドと通信し、必要に応じて検証インターフェイスを表示できます。
  • リクエストを受信した後、拡張機能は最初にアップグレードが承認されているかどうかをバックエンドに確認します。また、アプリと拡張機能の間の共有コンテナーにあるログイン Cookie またはトークンを読み取ることもできます。
  • 認証が失敗した場合、拡張機能は失敗エラー コードを使用してリクエストをキャンセルします。ユーザーに理由を説明する必要がある場合、拡張機能はローカライズされた失敗理由エラー キーを通じてコピーを提供できます。
  • 承認が成功すると、バックエンドはパスワード変更を送信し、拡張機能は更新されたユーザー名とパスワードを使用してパスワード変更リクエストを完了します。
  • システムによって生成された強力なパスワードがサーバー側のルールに準拠していない場合は、パスワード ルールを使用して生成ルールを制限し、拡張 Info.plist のパスワード生成要件キーに要件を書き込むことができます。

Apple でサインインへのアップグレードをサポート

(11:39)「Apple でサインイン」にアップグレードするための前提条件は、アプリが Apple でサインインをすでにサポートしていることです。拡張機能は、Info.plist で Apple でサインインするためのアップグレードのサポートを宣言する必要もあります。システムがトリガーされると、拡張機能は既存のパスワード認証情報、サービス識別子、および空のパスワードを受け取ります。userInfo

(13:36) 承認が渡された後、拡張機能はシステムから Apple でサインインの資格情報を要求する必要があります。リクエストに応じて持参可能stateそしてnonce、Apple ID 認証情報のバックエンド検証に使用されます。拡張機能がサーバーに送信された後、アップグレードを完了するメソッドが呼び出されます。アップグレードが完了すると、システムはアップグレードに使用されたキーチェーンのパスワード認証情報を削除します。

キーポイント:

  • バックエンドは依然としてアップグレードの実行が許可されるかどうかの判断点であり、クライアントの状態だけに依存することはできません。
  • ユーザーが「Apple でサインイン」パネルをキャンセルしたりネットワークの問題により、システムは資格情報を取得できない可能性があり、拡張機能は失敗したパスに従って要求をキャンセルする必要があります。
  • サーバーがアカウントのバインドを完了すると、拡張機能はアップグレードが完了したことをシステムに通知します。
  • 「Apple でサインイン」に正常にアップグレードすると、このアカウントはパスワードを使用してログインできなくなります。

追加の検証が必要な場合にステップアップ UI を表示する

(15:08) 理想的なパスでは、拡張機能はインターフェイスを表示せずにアップグレードを完了できます。ただし、サービスで SMS の 2 段階認証などの 2 段階認証が必要な場合、拡張機能はまずユーザーの操作が必要なエラー コードを使用して、最初の要求をキャンセルできます。次に、システムは対話を可能にする新しいリクエストを作成し、インターフェイスを準備するメソッドを呼び出します。

キーポイント:

  • 強力なパスワードのアップグレードにより、パスワードを変更するためのインターフェイスが準備されます。
  • Apple でサインインのアップグレードにより、アカウントを Apple でサインインに変換するためのインターフェイスを準備します。
  • システムは、ナビゲーション バー、アプリ名のタイトル、およびキャンセル ボタンを拡張機能インターフェイスに追加します。
  • ユーザーがキャンセルすると、システムはキャンセル要求を呼び出します。開発者がこのメソッドをオーバーライドした場合でも、リクエストはできるだけ早くキャンセルする必要があります。
  • 追加の検証が完了すると、プロセスは前の強力なパスワードの送信または Apple 資格情報でのサインイン要求に戻ります。

アプリ内で積極的にアップグレードを開始する

(18:06) 拡張機能が実装された後、アプリはアカウント設定ページでアクティブにアップグレードを開始できます。アプリはアップグレード リクエストを作成して実行し、システムは同じ拡張機能を起動します。アプリはクリアテキストのパスワードを提供すべきではなく、システムが保持するキーチェーン資格情報ハンドルがないため、アプリ内リクエストにはパスワードではなくユーザー名のみが含まれます。

(19:19) 強力なパスワード アプリ内アップグレードにはサービス識別子、ユーザー名、およびオプションでパスワードが必要ですuserInfo認可情報。スピーチ内の Shiny アプリは、現在ログインしているユーザーの認証トークンをuserInfo、拡張機能がそれを使用して、バックエンドへのアップグレードされたアクセス許可を確認できるようにします。実行をリクエストするとき、アプリはコントローラー デリゲートとプレゼンテーション コンテキスト プロバイダーも提供します。

(20:22) アプリ内「Apple でサインイン」のアップグレードは、リクエスト オブジェクトが異なるだけで、結果のコールバック メソッドは同じです。成功すると、デリゲート メソッドはユーザーに通知します。次に、システムは同じサービスとユーザー名のキーチェーン資格情報を検索し、アップグレードの種類に応じて更新または削除します。失敗した場合、デリゲート メソッドは失敗の理由を表示する責任があります。

キーポイント:

  • userInfoこれが、アプリ内アップグレードとシステム開始アップグレードの主な違いです。システムが開始したときは空ですが、アプリ内によって開始されたときに承認コンテキストを渡すことができます。
  • プレゼンテーション コンテキスト プロバイダーは、必要な UI をどのウィンドウに表示するかをシステムに指示します。
  • デリゲート成功コールバックは、[Apple でサインインするようにアップグレード] ボタンを非表示にするなど、アカウント設定ページのステータスを更新するのに適しています。
  • デリゲート失敗コールバックは、バックエンド承認の失敗、ネットワーク障害、ユーザーのキャンセルなどを、ユーザーが理解できるプロンプトにマッピングする必要があります。

重要ポイント

  • アカウント セキュリティ ページのワンクリック アップグレード 対処法: アカウント設定ページに「Apple でサインインするためのアップグレード」と「強力なパスワードへの切り替え」を追加します。 実行する価値がある理由: このスピーチでは、アプリ内アップグレードではシステムに統合されたアカウント セキュリティ アップグレード プロセスを再利用できることが明確に説明されています。成功すると、システムはキーチェーン認証情報を更新または削除します。 開始方法: まず、アカウント認証変更拡張機能を実装し、次にサービス識別子、ユーザー名、およびuserInfoアプリ内アップグレード リクエストの作成のログイン トークン。

  • 漏洩したパスワードのクイック修正パス 対処法: パスワードが脆弱であったり、パスワードが漏洩したりしたためにユーザーがログインした場合、アプリを終了せずに修復アクションを提供します。 実行する価値がある理由: iOS 14 では、ユーザーが危険なパスワードを使用してアプリにログインするとシステム プロンプトが表示され、拡張機能はこのプロンプトを実際のアカウント変更プロセスに接続できます。 開始方法: 拡張機能で強力なパスワード変更をサポートし、バックエンドで新しいパスワードを送信するためのアップグレード インターフェイスを追加し、デフォルトの強力なパスワードが既存のパスワード ルールに準拠しているかどうかを確認します。

  • セキュリティ アップグレードには二次検証が必要です 対処法: リスクの高いアカウントの場合は、SMS 認証コードを要求するか、アップグレード前に 2 段階認証をすでに行ってください。 実行する価値がある理由: セキュリティ ステップアップ UI の拡張サポートにより、システム アップグレード エントリを保持しながら、サービス独自の認証要件を完了できます。 開始方法: バックエンドが「さらなる認証が必要」を返したら、拡張機能がユーザーの対話が必要なエラー コードを含む対話型リクエストをトリガーし、拡張機能インターフェイスで検証を完了します。

  • アプリクリップから完全なアプリへのアカウントリンク 対処方法: ユーザーが App Clip から完全なアプリに入った後、一時アカウントまたはパスワード アカウントをより安全なログイン方法にアップグレードするようにガイドします。 実行する価値がある理由: この講演では、アカウントのセキュリティをアップグレードする機会として、アプリクリップからフルアプリへの移行を挙げています。 開始方法: 完全なアプリにログインした後、アカウント設定またはオンボーディングの最後にアプリ内アップグレード リクエストを開始し、現在のログイン ステータスをuserInfo拡張ライセンスで利用可能です。

  • 共有コンテナでの拡張ライセンス 対処法: アプリと拡張機能がログイン Cookie またはトークンを共有できるようにして、アップグレード中の繰り返しのログインを減らします。 実行する価値がある理由: この講演では、拡張機能が共有データ コンテナに保存されているログイン状態を再利用できるため、可能な限り迅速かつ中断を最小限に抑えてアップグレードできることが示唆されています。 開始方法: 拡張機能を同じアプリ グループに追加し、アップグレードの承認に必要な短期状態のみを保存し、システム リクエストを受信した後にバックエンドにアクセスする前に拡張機能に共有コンテナーを読み取らせるようにします。

関連セッション

  • どこでも自動入力 — アカウント アップグレード入口のシステム基盤である、パスワードの自動入力、セキュリティ コードの自動入力、強力なパスワードの自動入力について説明します。
  • Apple でサインインを最大限に活用する — Apple でサインインのリクエストの検証、ステータス処理、既存のアカウントの移行について説明します。
  • Web 用の Face ID と Touch ID について — Web サイトが Web 認証 API を使用して Face ID と Touch ID にアクセスしてログインする方法について説明します。
  • App Clip を構成してリンクする — 関連ドメインと App Clip の構成について説明します。これは、このセッションの App Clip アップグレードの提案に関連付けることができます。

コメント

GitHub Issues · utterances