Meet Face ID and Touch ID for the web

ハイライト

Apple は、Face ID と Touch ID を WebAuthn プラットフォーム認証システムとして Safari Web サイトに公開し、ユーザーが従来のログインを完了した後、デバイスの秘密キーと生体認証を使用して以降のログインを完了できるようにします。

主要内容

多くの高セキュリティ Web サイトでは、ユーザーは一定期間後に再度ログインする必要があります。銀行業務、支払いシステム、バックエンド管理システムはすべて共通です。従来のプロセスは通常、ユーザー名、パスワード、SMS 確認コードで構成されます。 iOS のオートフィルでは入力の一部が減りましたが、ユーザーは依然としてフィールドを判断し、確認コードを待ち、注意を切り替える必要があります。

このセッションでは、Shiny と呼ばれるデモ Web サイトを使用して、Safari の新しいパスを説明します。ユーザーは最初に元の資格情報を使用してログインし、Web サイトは Face ID と Touch ID のどちらをオンにするかを尋ねます。 Safari をオンにすると、次回ログインするときに確認インターフェイスがポップアップ表示されます。ユーザーが生体認証を完了すると、Web サイトは Web 認証 API (WebAuthn) によって返された資格情報を取得し、サーバー側でそれを検証します。

WebAuthn の主な変更点は、認証マテリアルが再利用可能なパスワードではなくなったことです。 Web サイトは証明書利用者であり、ブラウザーは PublicKeyCredential を作成し、秘密キーは認証者によって管理されます。 Apple のプラットフォーム認証システムは、Face ID または Touch ID と Secure Enclave を組み合わせたものです。ユーザーはデバイスを所有し、同時に生体認証によって身元を確認します。

これは、「次回ログイン」の高速レーンに適している理由も説明しています。資格情報は、それを作成した Web サイトでのみ使用でき、秘密キーは認証システムからエクスポートできず、再利用可能な秘密はフィッシング サイトによって取得できません。秘密キーはデバイスにバインドされており、ユーザーがデバイスを紛失したときにロックアウトできないため、Web サイトは依然としてパスワード、検証コード、またはその他の回復方法を保持する必要があります。

詳細

最初に能力テストを行う

(06:49) アクセスは 3 つの Promise ベースの API エントリから始まります。最初の入り口は、PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable。現在のデバイスがユーザー認証機能を備えたプラットフォーム認証システムを使用できるかどうかをページに示すブール値を返します。

// Feature detection

const isAvailable = await PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable();

if (isAvailable) {
    // Continue to enrollment or sign in
    // ...
}

キーポイント:

• PublicKeyCredentialWebAuthn の公開キー資格情報を表すブラウザ API です。
• isUserVerifyingPlatformAuthenticatorAvailable()Face ID や Touch ID を備えたデバイスなど、プラットフォームに組み込まれた認証システムを検出します。
• isAvailabletrue の場合、ページは登録またはログインのプロンプトに入ります。
• セッションでは、ユーザー エージェントの文字列判定ではなく、特徴検出を使用することを明確に推奨しています。

登録時に PublicKeyCredential を作成する

(07:56) ユーザーはまず従来の方法を使用してログインする必要があります。 Web サイトはユーザーの身元を確認した後、Face ID または Touch ID を有効にするための通知を表示します。ユーザーが同意すると、ページが呼び出します。navigator.credentials.create、Safari に確認 UI を処理させ、PublicKeyCredential。

// Enrollment

const options = {
    publicKey: {
        rp: { name: "example.com" },
        user: {
            name: "[email protected]",
            id: userIdBuffer,
            displayName: "John Appleseed"
        },
        pubKeyCredParams: [ { type: "public-key", alg: -7 } ],
        challenge: challengeBuffer,
        authenticatorSelection: { authenticatorAttachment: "platform" },
        attestation: "direct"
    }
};

const publicKeyCredential = await navigator.credentials.create(options);

キーポイント:

• rp現在の Web サイトが誰であるかをブラウザに伝えます。 WebAuthn は、この Web サイトを証明書利用者と呼びます。
• userユーザー情報を入力すると、サーバーは返された資格情報をこのアカウントに関連付けることができる必要があります。
• pubKeyCredParamsWeb サイトが使用する公開キー資格情報の種類と暗号化アルゴリズムを宣言します。
• challengeリプレイを防ぐために使用されるサーバー生成のチャレンジ値です。
• authenticatorAttachment: "platform"はこのコードの中核であり、プラットフォーム認証システムの使用を必要とします。
• attestation: "direct"Shiny デモ サイトにとっては安全な選択です。 Transcript description attestation はオプションの機能で、デバイス属性を証明する必要があるシナリオに適しています。

(10:00) フロントエンドが取得するのは登録応答であり、真の信頼はバックエンドで構築されます。サーバーは資格情報 ID と公開鍵データを保存する必要があります。また、クライアント データ、認証データ、および構成証明が有効な場合は構成証明ステートメントも検証します。

ログイン時にアサーションを取得する

(11:24) 登録が完了すると、Web サイトで Touch ID または Face ID をクイック ログイン ポータルとして使用できるようになります。 Session では、登録時にサーバー側の安全な HttpOnly Cookie を設定して、このアカウントがこのデバイスでこの機能を有効にしたことをマークすることをお勧めします。ログイン ページにこのマークが表示されると、クイック パスが表示されます。

// Sign in

const options = {
    publicKey: {
        challenge: challengeBuffer,
        allowCredentials: [{
             type: "public-key",
             id: credentialIdBuffer,
             transports: ["internal"]
        }]
    }
};

const publicKeyCredential = await navigator.credentials.get(options);

キーポイント:

• ログインは引き続きサーバーから発行されますchallenge始める。
• allowCredentials今回使用する認証IDを指定することで、Safariはよりダイレクトなインターフェースをユーザーに提供することができます。
• transports: ["internal"]対応するプラットフォームには認証機能が組み込まれています。
• navigator.credentials.get(options)Safari の確認画面をトリガーし、新しい画面を返しますPublicKeyCredential。
• 登録と同様に、この呼び出しはユーザーによってアクティブにトリガーされたイベントで発生する必要があります。

(12:38) ログイン応答の中核となる内容は署名です。サーバーは、ユーザー ID がサイト ユーザーに属していること、資格情報 ID がそのユーザーに関連付けられていること、メタデータが有効であることを確認してから、署名を検証する必要があります。検証に合格すると、ログイン セッションが確立されます。

構成証明と回復パスの処理

(05:39) 証明書は、デバイスが宣言したセキュリティ属性を備えていることを Web サイトが確認できるようにするために使用されます。また、トランスクリプトは、不適切な認証設計がクロスサイト追跡ベクトルになる可能性があることを思い出させます。 Apple の匿名認証は、Web サイトが同じ認証証明書を使用してユーザー アカウントに接続することを防ぐために、資格情報ごとに一意の証明書を生成します。

(14:02) 最も重要な製品ルールは次のとおりです。Face ID と Touch ID は唯一のログイン方法ではなく、代替ログイン方法である必要があります。秘密キーはデバイスにバインドされます。デバイスを紛失した場合、ユーザーは他のメカニズムを通じてアカウントを回復できる必要があります。すでにセキュリティ キーをサポートしている Web サイトでは、プラットフォーム認証システムと外部セキュリティ キーのエクスペリエンスの違いも考慮する必要があります。

重要ポイント

1. Face ID ファスト レーンを高頻度の再ログイン プロセスに追加します

内容: ユーザーがパスワードと確認コードを使用してログインを完了した後、現在のデバイスで Face ID または Touch ID をオンにするように求められます。

実行する価値がある理由: Session の Shiny デモは、その後のログインがパスワードと SMS 認証コードから Safari 確認と生体認証に短縮できることを示しています。

開始方法: まず接続しますisUserVerifyingPlatformAuthenticatorAvailable()、開始ポータルは、プラットフォーム認証をサポートするデバイスにのみ表示されます。

2. WebAuthn 登録結果をアカウント セキュリティ バックグラウンドに組み込む

対処方法: 認証情報 ID と公開キー データを保存し、ユーザーがアカウント セキュリティ ページで有効なデバイスを表示および削除できるようにします。

実行する価値がある理由: トランスクリプトでは、サーバーが登録中にこのデータを保存する必要があり、その後のログインも資格情報 ID とユーザーの間の関連付けに依存します。

開始方法: 登録コールバックから始まるサーバー側検証リストを完成させます: クライアント データ、認証データ、オプションの構成証明ステートメント、資格情報 ID、公開キー データ。

3. WebAuthn ログイン用に別の回復パスを設計します

対処方法: パスワード、確認コード、またはその他の回復エントリを保持したまま、Face ID または Touch ID を簡単にログインできる場所に置きます。

これを実行する価値がある理由: Apple は、秘密キーはデバイスにバインドされており、デバイスを紛失した場合にユーザーがアカウントから永久にロックアウトされることはないことを明確に注意しています。

開始方法: WebAuthn を有効にする前にアカウント回復プロセスを確認し、ユーザーが新しいデバイスで従来のログインと登録を再度完了できることを確認します。

4. デバイス属性の認証が必要な場合にのみ認証を有効にします

対処方法: 通常の Web サイトは、デフォルトでは証明書を要求しません。高度なコンプライアンスのシナリオでは、デバイス メーカーの認定が必要かどうかを再評価します。

実行する価値がある理由: Transcript は、証明書をオプションのセキュリティ機能として位置づけており、適切に設計されていない場合はプライバシー リスクを引き起こす可能性があると説明しています。

開始方法: まず、認証なしでオンライン登録の応答を完了します。実際にコンプライアンス要件がある場合は、認証ステートメントを確認し、Apple 匿名認証に注意してください。

5. デバイスレベルのプロンプトにはセキュア Cookie を使用し、認証情報として扱わないでください

手順: 登録が成功したら、サーバー側のセキュア Cookie と HttpOnly Cookie を設定します。これらの Cookie は、このデバイスにクイック ログイン入り口があることを確認するためにのみ使用されます。

実行する価値がある理由: セッションでは、より長期間持続するデバイス トークンを取得するためにこの Cookie を使用することを推奨していますが、実際のログインは依然として WebAuthn 署名検証によって行われます。

開始方法: Cookie をログイン ページ表示ロジックにのみ接続します。サーバーは、ユーザー ID、資格情報 ID、メタデータ、署名に基づいて認証を完了します。

関連セッション

• ワンタップ アカウント セキュリティ アップグレード — Apple でサインイン、強力なパスワード、iCloud キーチェーン パスワード マネージャーなど、アカウント セキュリティ アップグレードについて引き続き説明します。
• Apple でサインインを最大限に活用する — ログイン要求、認証情報のステータス、サーバー通知、既存のアカウントの移行について説明します。
• どこでも自動入力 — 従来のログイン フォームでのアカウント番号、パスワード、確認コードの自動入力エクスペリエンスを完了します。
• Web 開発者向けの新機能 — 同年からの Safari および WebKit プラットフォーム API の全体的な更新をご覧ください。