Passkey

Passkey とは

Passkey は、公開鍵暗号を使ったパスワードレス認証の仕組みで、W3C の Web Authentication (WebAuthn) 仕様と FIDO Alliance の CTAP を組み合わせた FIDO2 の上に成り立つ。標準の帰属は分かれており、ブラウザから認証器を呼び出す API を定めるのが W3C で、WebAuthn Level 2 は 2021 年 4 月 8 日に W3C 勧告となり、Level 3 は 2026 年 8 月時点では候補勧告の段階にある。端末と外部認証器をつなぐ CTAP を定めているのは FIDO Alliance である。Passkey は仕様の名前ではなく、この方式で作られた資格情報を指す呼び名として使われる。生体認証 (指紋、顔) や PIN でデバイスのロックを解除するだけでログインでき、パスワードの記憶、漏洩、フィッシングのリスクを根本的に排除する。

2026 年 8 月時点では、Android と Chrome では Google パスワードマネージャー、Apple 製デバイスでは iCloud キーチェーンがパスキーの保管と同期を担い、主要ブラウザが WebAuthn に対応している。ただし利用者の環境とサービス側の実装状況には差があるため、導入はパスワード認証との併存を前提に設計する。

パスワード vs Passkey

両者の差は、利用者が覚えた秘密をそのまま送るか、デバイスが持つ秘密鍵で署名だけを返すかという構造の違いに由来する。送るものが秘密そのものでなくなるため、入力を盗む攻撃と保存された秘密を盗む攻撃が同時に成立しなくなる。

観点	パスワード	Passkey
フィッシング	偽サイトに入力するリスク	接続先の情報が署名の対象に入るため偽サイト向けの署名は検証に通らない
漏洩	DB 侵害で大量流出	サーバーが持つのは公開鍵だけで、盗んでも認証できない
使い回し	ユーザーが同じパスワードを流用	サイトごとに固有の鍵ペア
UX	記憶・入力の負担	生体認証でワンタッチ
ブルートフォース	試行可能	推測対象が秘密鍵になり、総当たりは現実的な計算量で成功しない

認証の仕組み

処理は登録と認証の 2 段階に分かれ、どちらもサーバーが送るチャレンジにデバイスが応答する形を取る。

[登録]
1. サーバーがチャレンジを送信
2. デバイスが鍵ペア (公開鍵 + 秘密鍵) を生成
3. 秘密鍵は認証器の保護領域か、パスキー提供元の暗号化された保管領域に保存
4. 公開鍵をサーバーに送信・登録

[認証]
1. サーバーがチャレンジを送信
2. ユーザーが生体認証でデバイスをロック解除
3. デバイスが秘密鍵でチャレンジに署名
4. サーバーが公開鍵で署名を検証

秘密鍵がネットワークを流れず、サーバーに渡るのは公開鍵だけなので、通信の傍受やサーバー側のデータ流出だけでは認証を突破できない。ただしフィッシング耐性は鍵の置き場所から生じるのではなく、署名の対象に接続先の情報が含まれる点から生じる。認証器は登録時の RP ID に紐づく資格情報しか使わず、ブラウザが添える clientDataJSON にも実際のオリジンが入るため、サーバーがこの 2 つを照合すれば偽サイト経由の署名は弾かれる。

パスキーには、端末間で複製される同期パスキーと、機器から出ないデバイス固定のパスキーという区別がある。前者は iCloud キーチェーンや Google パスワードマネージャーが暗号化した状態で同期するため、機種変更でも同じ資格情報を引き継げる。後者はセキュリティキーのようなローミング認証器に作った資格情報で、複製されない代わりに紛失すると復旧できない。要求水準が高い用途では、利便性より非複製性を選ぶ判断もある。

もう一つの軸が discoverable credential (resident key とも呼ぶ) かどうかである。discoverable credential では利用者の識別情報まで認証器側に保存されるので、サーバーが候補の資格情報 ID を提示しなくても、ブラウザが手元のパスキー一覧を出してログインできる。これがユーザー名を入力しないログインを成立させている。非 discoverable な資格情報は鍵素材や利用者情報をサーバー側に預ける形になり、認証開始時にサーバーから資格情報 ID を渡す必要がある。

FIDO2 の構成要素

FIDO2 は単一の仕様ではなく、策定元の異なる 2 つの仕様と、それを実行する認証器の組み合わせを指す呼び方である。

要素	役割
WebAuthn	W3C が策定するブラウザ API。Web アプリから認証器に鍵生成と署名を要求する
CTAP2	FIDO Alliance が策定する、デバイスと外部認証器の通信プロトコル
認証器	プラットフォーム認証器 (Touch ID, Windows Hello) / ローミング認証器 (YubiKey)

Cognito での Passkey

Amazon Cognito のユーザープールはパスキーによるサインインに対応しており、Managed Login からでも API 経由でも利用できる。API では認証フローに USER_AUTH を指定し、PREFERRED_CHALLENGE に WEB_AUTHN を渡すと WEB_AUTHN チャレンジが返るので、認証器から得た応答を CREDENTIAL として送り返す。2026 年 8 月時点では 1 アカウントあたり 20 個までパスキーを保存できる。パスワードと MFA の構成を残したまま並行提供し、段階的に移行させる形が取りやすい。

導入の注意点

• デバイス紛失時のリカバリ: iCloud キーチェーンや Google パスワードマネージャーの同期に載るパスキーは新しい端末へ引き継げるが、セキュリティキーに作ったパスキーは引き継げない。復旧用の別手段か、複数の認証器の登録を必ず用意する
• レガシーブラウザ: WebAuthn 非対応のブラウザにはパスワード認証をフォールバックとして残す
• 段階的導入: 既存のパスワード認証と並行して Passkey を提供し、ユーザーに移行を促す

関連書籍も参考になる。