WebAuthnはブラウザーと認証器を介し、パスワードの代わりに公開鍵資格情報で利用者を認証する手順を定義します。passkeyはこのプロトコルを利用する資格情報体験であり、サイトは検証用の公開鍵を保存し、認証器は対応する秘密鍵で署名します。実際には秘密鍵が端末内の認証器や同期サービスで管理されることがあるため、常に一台の物理端末だけに固定されるとは限りません。

1. 登録時のサイトと認証器の役割

資格情報を登録するとき、サーバーはchallengeとrelying party情報をブラウザーに渡します。利用者の操作とポリシーに基づき、ブラウザーは端末内認証器やセキュリティキーなど利用可能な認証器を呼び出します。認証器はユーザーの存在確認と、設定されている場合はユーザー検証を行い、新しい資格情報の公開鍵情報を返します。サーバーは応答を検証し、credential IDと公開鍵をアカウントに保存します。

保存した公開鍵は後のログイン署名の検証に使います。登録challengeは一度だけ使い、originやrelying party IDなど手順の文脈もサーバーで確認します。ブラウザーと認証器がAPIを実行したからといって、サーバー検証を省略できるわけではありません。challenge、origin、資格情報データ、適用ポリシーを確認してから登録を信頼します。

2. ログインassertionの検証

ログインではサーバーが新しいchallengeを発行し、ブラウザーに既存資格情報によるassertionを要求します。ブラウザーはchallengeを含むclientDataJSONを作成し、そのSHA-256ハッシュを認証器に渡します。認証器はauthenticator dataとこのハッシュを連結したデータに対応する秘密鍵で署名するため、challengeのバイト列だけに署名するわけではありません。サーバーは保存した公開鍵で署名を検証し、challengeが新しく現在のセッションに属することを確認します。challengeの再利用、予期しないorigin、異なるrelying partyの文脈を成功扱いしてはいけません。

credential IDは認証器に対応する鍵を探す識別子として働きます。ユーザー存在とユーザー検証は別の概念です。前者は利用者が認証手順に参加したことを示し、後者はPINや生体認証など設定された方法で認証器が利用者を確認したことを示す場合があります。サービスはアカウントリスク方針に必要な水準を要求し、これらの信号を混同しないようにします。

3. passkey同期とアカウント復旧

プラットフォームによっては、複数端末で使えるようpasskeyを同期できます。一方、セキュリティキーのような別の認証器に保持する資格情報もあります。WebAuthnはサイトと認証器のプロトコルを定義しますが、すべての提供者に共通する同期、バックアップ、復旧方式までは定めません。製品では復旧手順、新端末を登録する方法、紛失端末に関連する資格情報を無効化する経路を用意します。

公開鍵認証はパスワードの使い回しを減らせますが、アカウント復旧や端末エコシステムのリスクをなくすわけではありません。すべての認証器を失った場合にどのような確認で復旧するか、復旧後に古い資格情報をどう失効させるかを事前に決めます。利用可否やpasskeyの移行性はプラットフォームと提供者の設定に依存するため、「一台の紛失で必ずログインできない」「全端末に必ず自動復旧する」とは約束しません。

4. 導入前のセキュリティと運用確認

W3C仕様はブラウザーが仲介する作成・認証手順と検証データの意味を定めます。MDNのWeb Authentication案内は公開鍵登録と認証の開発者向け概要を示します。どちらもサービス固有のサーバー検証を代行しません。challengeの生成・有効期間・一回性、originとRP IDの一致、資格情報の状態、要求するユーザー検証方針をサービス側で確認する必要があります。

公開前にHTTPSと許可されたoriginで登録・ログインを試し、未対応ブラウザーの代替手段とアカウント復旧も検証します。機微な認証応答全体や秘密情報をログに残さず、検証エラー、利用者のキャンセル、機能非対応を区別します。passkeyはパスワードなしの認証を可能にしますが、復旧、セッション管理、アクセス制御まで自動で解決するものではありません。

参考資料