目次
パスキーを会員サイトへ追加すると、利用者は端末のPINや生体認証などを使ってログインでき、パスワードを偽サイトへ入力させる攻撃への耐性を高められます。導入時に決める範囲はログイン画面だけではありません。誰が認証情報を追加できるか、端末を失ったらどう戻すか、古い認証情報をどう止めるかが、アカウント全体の安全性を左右します。
本稿は2026年10月22日にW3C、OWASP、Googleの一次資料を確認した恒久対策の解説です。新たな脆弱性や特定サイトの侵害を報じるものではありません。既存の会員サイトへ段階導入する仮想例を用い、設定、保存、運用、検証の順に整理します。以下の導入手順や合格条件は本サイトの提案です。
スポンサーリンク
先に決めるのは利用者とドメインの範囲
パスキーはWebAuthnの公開鍵認証情報として使われます。サイト側は公開鍵を保存し、認証器側が管理する秘密鍵による署名を検証します。認証情報はRP IDと呼ぶ識別子の範囲に結び付き、サーバーはオリジンやチャレンジも照合します。仕様の基礎はW3C：Web Authentication Level 3で確認できます。
例えば会員画面がmembers.example.com、古いキャンペーンがpromo.example.comにあるなら、同じ親ドメインだからという理由で利用範囲を広げないようにします。将来のドメイン変更、サブドメインの委託運用、スマートフォンアプリとの連携を洗い出してから、安定したRP IDと許可オリジンを決めます。
本サイトでは、まず会員Web画面一つを対象にし、アプリや別ブランドへの展開を別工程にすることを勧めます。仕様書には環境ごとのRP ID、HTTPSのオリジン、責任者、変更時の移行方法を記載します。ステージング用の許可値が本番へ混ざることも、レビューの対象です。
一人の会員に複数の認証情報を持たせる
GoogleのGoogle for Developers：Server-side passkey registrationは、ユーザー識別子や既存の認証情報を基に登録オプションを作り、返された情報を検証して保存する流れを説明しています。ユーザー識別子は長期的に安定したものとし、メールアドレス変更によって別会員へ結び直される設計を避けます。
実装案として、会員テーブルと認証情報テーブルを分けます。会員一人に対して、認証情報ID、公開鍵、アルゴリズムなどライブラリが必要とする情報、作成日時、最終利用日時、利用者が付けた表示名、失効状態を複数保存できる構成にします。表示名は「仕事用の認証手段」など、本人が識別できれば十分です。
認証情報IDには一意性を保証し、同じIDが別会員へ登録されそうになったら調査できるエラーにします。更新処理で所有者IDを上書きする動作は作りません。端末名や提供元の表示だけで、認証情報の所有者や信頼度を決めないことも大切です。
データ移行では、公開鍵の形式、エンコード、会員との対応が維持されるかを検証します。秘密鍵を会員サイトのデータベースへ集める仕組みは必要ありません。一方、公開鍵しか持たないからといって、認証情報と会員の対応関係を自由に編集してよいわけでもありません。
スポンサーリンク
登録は権限を増やす操作として扱う
GoogleのGoogle web.dev：Create a passkey for passwordless loginsは、登録前に短い時間内の安全な本人確認を行うことを求め、パスワードだけの確認を避けるよう注意しています。漏えいしたパスワードでログインした第三者が、自分のパスキーを追加できると、後からパスワードを変更しても入口が残り得ます。
仮想の会員サイトなら、既に登録された強い認証手段による再確認を追加時に求めます。初回登録では、既存会員の本人確認方針に合わせた手続きを用意し、新規会員では会員作成のトランザクションへ登録を結び付けます。長期間有効なログインCookieだけで登録が完了しないようにします。
登録開始時に、対象会員、登録処理であること、有効期限、期待するRP IDとオリジンをサーバー側へ記録します。完了要求の会員IDをそのまま保存先に使わず、開始時に確定した会員へ紐付けます。複数タブで別アカウントへ切り替えた場合にも、この対応が崩れないことを確かめます。
暗号処理と応答検証には保守されているWebAuthnライブラリを使います。ライブラリへ渡す期待値と、チャレンジの発行・期限・一回限りの消費はアプリ側の責任範囲として明文化します。保存が成功した後に登録完了を表示し、途中で通信が切れた場合は再読取して状態を案内します。
端末操作と本人確認を区別する
認証時はGoogle for Developers：Server-side passkey authenticationに沿って、署名、チャレンジ、RP ID、オリジン、認証情報と会員の対応をサーバーで検証します。端末を操作したことを示すUPと、PINや生体認証などによる本人確認を示すUVは別の情報です。必要な本人確認を行ったかは、返されたフラグまで確認します。
管理者や送金機能を持つ会員など、強い本人確認が必要な用途では、要件を満たさない応答を拒否する方針を先に決めます。フロント側でuserVerificationを指定しても、それだけを根拠に認証済みとは扱いません。検証がすべて成功した後にアプリのセッションを発行します。
試験では、別会員の認証情報、使用済みチャレンジ、期限切れ、想定外オリジン、必要なUVの欠落を個別に拒否できるか確認します。署名が正しい場合でも、今の処理や会員に対応していなければ通さないことが重要です。
スポンサーリンク
既存のパスワード利用者も迷わない画面にする
GoogleのGoogle web.dev：Sign in with a passkey through form autofillは、ログインフォームの自動入力候補へパスキーを表示するConditional UIを説明しています。対応環境では、ユーザー名欄のautocompleteにusernameとwebauthnを指定し、条件付きの認証要求を使って既存パスワードと併存させられます。
導入前に、主要ブラウザー、スマートフォン、PC、端末をまたぐ操作を試します。機能の有無は実行時に確認し、対応しない環境でも画面が固まらないようにします。キャンセルやタイムアウトを、直ちにアカウント侵害と判定する必要はありません。
本サイトの提案は、ログイン成功後に登録を案内し、作成を断った利用者へ毎回強制表示しないことです。表示された候補のアカウントを本人が選べる状態を保ち、共有PCで別人の会員へ入っていないかを分かりやすくします。導入率だけでなく、ログイン完了率と問い合わせ件数を見て改善します。
紛失と同期を前提に復旧を設計する
パスキーには同期されるものと特定の認証器に結び付くものがあります。OWASP：Passkey Security Cheat Sheetは、複数の認証手段を登録できることと、認証に見合う復旧経路を用意することを勧めています。同じ同期アカウントに属する二つの端末だけで、独立した予備手段が完成したと考えないようにします。
復旧案として、別に登録した認証手段、適切に保管した一回限りの復旧コード、サービスのリスクに応じた本人確認を検討します。氏名、住所、生年月日が一致するだけで全認証情報を解除する窓口運用は避けます。担当者が何を確認し、誰が承認するかを手順にします。
仮想のECサイトでは、復旧直後に配送先を変えて高額注文する操作へ追加確認を求める設計が考えられます。すべての会員へ一律の待機時間を課すのではなく、復旧方法と操作の影響に応じて条件を決めます。復旧成功後には既存の信頼済み連絡先へ通知し、認証情報とセッションを見直せる画面へ案内します。
削除はサーバー側の失効まで完了させる
管理画面では表示名、作成日時、最終利用日時を見せ、利用者が不要な認証情報を選べるようにします。削除には最近の本人確認を求め、最後の手段を消す前に利用可能な別手段があるかを確認します。サポート担当者による削除も、対象と理由を記録する操作にします。
サーバーで失効した認証情報は、端末の候補に残っていてもログインを拒否する必要があります。逆に、利用者が一台の端末から削除したことだけで、サーバー側や同期先すべての状態まで変わったとは扱いません。画面の表示と認証の許可状態を分けて確かめます。
認証情報の削除と、既存のログインセッションの終了は別の処理です。紛失端末への対応票では、認証情報の失効、端末上のセッション停止、同期アカウントの保護を担当別に記録します。詳しい失効の考え方は関連記事へつなぎ、操作漏れを減らします。
公開判定は正常系と拒否系で行う
- 正常系：初回登録、二つ目の登録、別端末でのログイン、表示名変更が意図した会員にだけ反映される
- 拒否系：別会員への付け替え、失効済み認証情報、チャレンジの再利用、本人確認不足を拒否する
- 障害系：登録後の通信断、キャンセル、ライブラリ障害、データベース障害で状態が食い違わない
- 復旧系：紛失から復旧し通知とセッション見直しを行い重要操作の条件が維持される
まずテスト会員と少人数の利用者へ展開し、登録開始数、保存完了数、ログイン成功数、復旧要求数を計測します。生の認証応答やセッションIDをログへ保存せず、イベント種別と結果、内部の相関IDで調査できるようにします。
画面にパスキーボタンがあることに加え、登録、通常利用、紛失、復旧、失効の各段階で期待した会員だけが利用できることを公開条件にします。パスワードを残す期間も、その入口の追加認証や復旧方針を維持し、段階的に運用実績を見て移行します。
スポンサーリンク
関連記事
デバイスコード・フィッシングとMFAの限界では、正規の認証画面でも承認先の確認が必要な理由を説明しています。2026年10月13日時点の事例解説であり、本稿の実装手順と合わせて確認できます。
ログアウト後も使えるセッションを残さないための失効設計は、認証情報を削除した後の既存アクセスを点検する際に役立ちます。
