ブログ・ 2026年7月28日

FIDO2解説：WebAuthn、パスキー、そしてセキュリティ (JA)

FIDO2に関する技術ガイド：WebAuthnとCTAPの役割、登録と認証のプロセス、パスキー、フィッシング耐性、アテステーション、リカバリー、展開における落とし穴について解説します。.

By Didit2026年7月28日更新日 2026年7月28日

FIDO2は、2つの公開鍵認証規格から構成されています。World Wide Web ConsortiumのWeb Authentication API（WebAuthn）とFIDO Alliance Client to Authenticator Protocol（CTAP）です。これらを組み合わせることで、依拠当事者は、パスワードのような再利用可能な共有秘密情報を保存することなく、暗号化された認証情報を登録し、使用することができます。

FIDO2は、適切に実装および検証された場合、フィッシング耐性およびリプレイ耐性のある認証を提供できます。ただし、個人の法的身元を証明したり、誰が登録を許可されるべきかを決定したり、侵害されたサーバーセッションを保護したり、脆弱なアカウント回復プロセスを修正したりするものではありません。これらは、認証プロセスを中心に設計されるべき隣接する制御です。

重要なポイント

FIDO2はWebAuthnとCTAPの組み合わせです。 WebAuthnはウェブサイトまたはアプリケーションをクライアントに接続し、CTAPはクライアントプラットフォームをローミングオーセンティケーターに接続します。
秘密鍵はオーセンティケーターに保持されます。 依拠当事者は公開鍵を保存し、新しいチャレンジとスコープされたコンテキストに対する署名を検証します。
ドメインバインディングがフィッシング耐性を生み出します。 ある依拠当事者識別子に登録された認証情報は、攻撃者の無関係なドメインに簡単にリプレイされることはありません。
パスキーはFIDO認証情報です。 これらはデバイスに紐付けられている場合と、プロバイダーのデバイス間で同期される場合があり、保証、回復、ポータビリティのトレードオフが異なります。
回復はセキュリティモデルの一部です。 メール、サポート、または身元回復の経路が、より弱い証拠で認証情報を置き換えることができる場合、強力なFIDO2ログインはバイパスされる可能性があります。

FIDO2とは？

FIDO Allianceの仕様概要では、FIDO2をW3C WebAuthn仕様とFIDO Client to Authenticator Protocolsの組み合わせと定義しています。この規格は、システムを連携する役割に分割しています。

依拠当事者（Relying party）： 認証情報を登録し、認証アサーションを検証するウェブサイトまたはサービス。
クライアント（Client）： 通常はWebAuthnを実装し、プロセスを仲介するブラウザまたはオペレーティングシステムコンポーネント。
オーセンティケーター（Authenticator）： 認証情報キーを作成し、使用するプラットフォームコンポーネントまたは外部デバイス。
ユーザー（User）： 登録または認証に同意し、PIN、パスワード、または生体認証でローカルに検証する人。

W3C WebAuthn Level 3仕様は、依拠当事者にスコープされた公開鍵認証情報を作成および使用するためのウェブAPIを定義しています。スクリプトが秘密認証情報キーを受け取ることはありません。オーセンティケーターとクライアントを通じて生成された構造化データと暗号証明を受け取ります。

FIDO2、WebAuthn、CTAP、U2F、パスキーの比較

用語	実用的な意味	主な境界
FIDO2	WebAuthnとCTAPの規格を組み合わせて使用	単一のAPI呼び出しではなく、完全な規格ファミリー
WebAuthn	公開鍵認証情報のためのブラウザまたはクライアントAPIおよび依拠当事者データモデル	依拠当事者をクライアントに接続する
CTAP2	クライアントプラットフォームとローミングオーセンティケーター間のプロトコル	USB、NFC、BLEなどのトランスポートを介して外部オーセンティケーター通信を伝送する
U2F / CTAP1	以前のFIDOプロトコルで、一般的に第2要素セキュリティキーに関連付けられる	現代のFIDO2機能よりも限定的
パスキー	パスワードレスサインイン用に設計された検出可能なFIDO認証情報	同期可能またはデバイスに紐付け可能
セキュリティキー	USB、NFC、またはサポートされている他のトランスポートで接続されるローミングハードウェアオーセンティケーター	可能なオーセンティケーター形式の1つ
プラットフォームオーセンティケーター	デバイスまたはオペレーティングシステムに組み込まれたオーセンティケーター	多くの場合、ローカルPINまたは生体認証でアクティブ化される

「パスワードレス」は、あらゆる可能な展開を指すのではなく、ユーザーのジャーニーを説明するものです。サービスはWebAuthnをパスワード後の第二要素として、主要な多要素認証情報として、または他のオーセンティケーターと並行して使用できます。依拠当事者は、保護されたアクションの保証を満たす認証情報の特性とフラグを決定する必要があります。

FIDO2登録の仕組み

クレデンシャル作成とも呼ばれる登録は、新しい公開鍵クレデンシャルを依拠当事者のアカウントにバインドします。

1. サーバーは登録オプションを作成します

依拠当事者は、予測不能な新しいチャレンジを生成し、公開鍵クレデンシャル作成オプションをクライアントに送信します。オプションは、依拠当事者、ユーザーアカウント、受け入れられるアルゴリズム、オーセンティケーターの優先設定、アテステーションの優先設定、および関連する場合は既存のクレデンシャル識別子の除外を特定します。

チャレンジは、単一使用、短命、正しいセッションとユーザーにバインドされ、サーバーによって保存または検証可能である必要があります。ブラウザのみで生成されたチャレンジは、サーバーのプロセスを保護できません。

2. クライアントはWebAuthnを呼び出します

アプリケーションは、公開鍵オプションを指定してnavigator.credentials.create()を呼び出します。ブラウザはオリジンとセキュリティコンテキストをチェックし、利用可能なオーセンティケーターにクレデンシャルの作成を要求します。

3. オーセンティケーターはユーザーの同意を得ます

オーセンティケーターはユーザーの存在を必要とし、要求されサポートされている場合はユーザー検証を行います。ユーザーの存在は、タッチまたは明示的な操作です。ユーザー検証とは、オーセンティケーターがPIN、デバイスの秘密、生体認証、またはサポートされている他の方法を通じてユーザーをローカルで検証することを意味します。

通常、ローカル生体認証はクレデンシャルの使用を解除します。生体認証テンプレートは、認証秘密としてウェブサイトに送信されません。

4. オーセンティケーターはキーペアを作成します

オーセンティケーターは、依拠当事者にスコープされたクレデンシャルキーペアを作成します。秘密鍵はオーセンティケーターまたはその同期ファブリックによって保護されたままです。結果として得られるクレデンシャルには、選択された形式に従って、公開鍵、クレデンシャル識別子、オーセンティケーターデータ、クライアントデータ、およびアテステーション情報が含まれます。

5. サーバーはクレデンシャルを検証して保存します

依拠当事者は、何かを保存する前にプロセスを検証します。チェックには以下が含まれます。

予期されるチャレンジ。
予期されるオリジン。
正しい依拠当事者識別子ハッシュ。
プロセスが埋め込まれている場合の予期されるクロスオリジン状態とtopOrigin。
ポリシーに応じたユーザーの存在とユーザー検証フラグ。
受け入れられるアルゴリズムとキーパラメータ。
アテステーションが要求された場合のアテステーション構造と信頼ポリシー。
一意性と正しいユーザーアカウントとの関連付け。

サーバーは、クレデンシャル識別子、公開鍵、アカウントバインディング、署名カウンターまたは適用可能な状態、有用な場合はトランスポートまたはメタデータ、およびクレデンシャルライフサイクル情報を保存します。秘密鍵は必要ありません。

FIDO2認証の仕組み

認証は、以前に登録された資格情報の制御を証明します。

1. サーバーはリクエストオプションを作成します

依拠当事者は新しいチャレンジを生成し、アサーションオプションを送信します。これには、資格情報識別子の許可リストを含めるか、オーセンティケーターがアカウントを識別できるように検出可能な資格情報を使用することができます。

2. クライアントはアサーションを要求します

アプリケーションはnavigator.credentials.get()を呼び出します。ブラウザとオーセンティケーターは適切な資格情報を選択し、必要なユーザーの存在またはローカルユーザー検証を取得します。

3. オーセンティケーターはプロセスデータを署名します

オーセンティケーターは、資格情報の秘密鍵を使用して、新しいチャレンジコンテキストとオーセンティケーターデータに署名します。資格情報は依拠当事者にスコープされているため、無関係なフィッシングオリジンは、オーセンティケーターに実際のサービスに対する有効なアサーションを生成するよう要求することはできません。

4. サーバーはアサーションを検証します

依拠当事者は、予期されるチャレンジ、オリジン、依拠当事者ハッシュ、保存されている公開鍵による署名、必要なフラグ、許可された資格情報、ユーザーバインディング、および関連するカウンターまたはバックアップ状態を検証します。その後にのみ、アプリケーションセッションを作成または昇格させるべきです。

各アサーションは、その時点での制御を証明します。セッション作成、トークン保護、再認証、トランザクション承認、ログアウト、および失効は、アプリケーションの個別の責任として残ります。

FIDO2がフィッシング耐性である理由

パスワードとワンタイムコードは、偽のサイトに入力され、それが実際のサービスに中継される可能性があります。FIDO2は、依拠当事者にスコープされた認証情報を使用し、アサーションを期待される検証コンテキストに暗号的にバインドします。

NIST SP 800-63B-4オーセンティケーター要件は、WebAuthnが検証者名バインディングを通じてフィッシング耐性を持つと説明しています。オーセンティケーターの出力は、ユーザーが欺瞞的なページに気づくことに依存するのではなく、認証されたドメイン名にバインドされます。

フィッシング耐性には限界があります。

マルウェアや、すでに認証済みセッションを制御している攻撃者を阻止することはできません。
ユーザーが正規のサービス内で悪意のあるトランザクションを承認することを防ぐことはできません。
認証情報を置き換えることができるアカウント回復パスを保護することはできません。
オーセンティケーターを制御している人物が、組織が登録を意図した実世界の人物であることを証明することはできません。

リプレイ耐性とチャレンジ処理

すべてのリクエストで新しいチャレンジが使用されるため、記録されたアサーションは後続のプロセスでは機能しないはずです。NISTは、ノンスまたはチャレンジを組み込んだ暗号化オーセンティケーターをリプレイ耐性があると説明しています。

実装エラーにより、その特性が失われる可能性があります。一般的な失敗には、予測可能なチャレンジ、チャレンジの再利用、間違ったアカウントに対するチャレンジの受け入れ、有効期限の強制なし、またはオリジンと依拠当事者のコンテキストを無視して署名のみを検証することなどが含まれます。

サーバーはチャレンジをアトミックに消費済みとマークする必要があります。並列リクエストが競合する場合、そのチャレンジを使用できるのは1つの成功したプロセスのみであるべきです。

ユーザーの存在とユーザー検証

WebAuthnは以下を区別します。

ユーザーの存在 (UP): ユーザーが参加を示すインタラクションを実行したこと。
ユーザー検証 (UV): オーセンティケーターがPINや生体認証などのアクティベーション要素を介してユーザーをローカルで検証したこと。

存在のみでは多要素認証ではありません。リスクの高いアクションを保護するサービスは、UVフラグを要求し、存在のみを示すアサーションを拒否する場合があります。要件は「Face IDを使用」のようなインターフェースラベルに依存するのではなく、予期されるフラグ値を明示的に示すべきです。

ローカル検証の品質もオーセンティケーターによって異なります。依拠当事者は、ユーザーが提供するオーセンティケーターの正確な生体認証またはPINの実装について限られた可視性しか持たない可能性があるため、ポリシーはトランザクションと展開されているユーザー数に比例すべきです。

プラットフォーム、ローミング、クロスデバイスオーセンティケーター

プラットフォームオーセンティケーター

これらは電話、ラップトップ、またはオペレーティングシステムに統合されています。デバイスのローカルアンロック方法を使用して簡単なジャーニーを提供できます。トレードオフは、プラットフォームアカウントの回復、デバイスのセキュリティ、および同期動作への依存です。

ローミングオーセンティケーター

外部セキュリティキーはデバイス間で持ち運びでき、サポートされているトランスポートを介して接続できます。これらは、特に資格情報の非エクスポート性と管理された発行が重要な場合、従業員、管理、または高保証のユースケースに役立ちます。

クロスデバイス認証

ハイブリッドフローでは、近くの電話を使用して別のデバイスのセッションを認証できます。ハンドオフと近接メカニズムはユーザビリティを向上させますが、同じデバイスの認証と同一視するのではなく、テストすべきユーザーインターフェースと脅威モデルの詳細を追加します。

アカウントごとに複数の認証情報をサポートします。ユーザーは電話を交換したり、セキュリティキーを紛失したり、仕事用と個人用のデバイスを使用したりするため、認証情報を安全に命名、検査、削除する方法が必要です。

デバイスに紐付けられたパスキーと同期されたパスキー

パスキーは、パスワードなしでのサインイン用に設計されたFIDO認証情報です。パスキーは次のいずれかになります。

デバイスに紐付けられた（Device-bound）： 認証情報の秘密鍵が1つのオーセンティケーターまたは管理対象デバイスに紐付けられたままになります。
同期された（Synced）： 認証情報が暗号化され、プロバイダーのファブリックを介して同期され、対象となるデバイス全体で使用されます。

同期されたパスキーは可用性と回復性を向上させますが、デバイスに紐付けられた認証情報はより強力な非エクスポート性を提供できます。NIST SP 800-63B-4の同期可能オーセンティケーターガイダンスでは、その要件が満たされる場合、認証保証レベル2までのコンテキストで同期可能オーセンティケーターを許可していますが、同期はレベル3で要求される非エクスポート性と矛盾します。

「パスキー」という言葉から保証を推測しないでください。認証情報がバックアップされているか、バックアップ可能か、共有されているか、管理されているか、デバイスに紐付けられているか、アテステーションされているか、依拠当事者のポリシーに従ってユーザー検証でアクティブ化されているかを評価してください。

アテステーションとオーセンティケーターの信頼

アテステーションは、登録時にオーセンティケーターの出所やプロパティに関する証拠を提供できます。これは認証署名とは異なり、人間のユーザーを特定するものではありません。

コンシューマーサービスは、プライバシーとエコシステムとの互換性のために、アテステーションの収集を最小限に抑えることがよくあります。管理された従業員展開では、特定のオーセンティケーターモデルや認証が必要になる場合があります。この決定は、デフォルトでデバイス識別情報を収集するのではなく、脅威モデルの質問に答えるべきです。

アテステーションを使用する場合：

受け入れられる形式と信頼アンカーを定義する。
証明書パスとステートメントを正しく検証する。
メタデータの更新と失効処理を指定する。
信頼できるアテステーションを持たないオーセンティケーターを計画する。
プライバシーと保持の結果を文書化する。
受け入れられたモデルのステータスが変更された場合の交換をテストする。

FIDO2は身元確認に代わるものではありません

FIDO2は、依拠当事者に登録された認証情報の制御を証明します。それは、登録する人物の法的氏名、年齢、住所、規制上のステータス、または実世界での一意性を確立するものではありません。

この区別により、3つの一般的なパターンが生まれます。

仮名登録: サービスは安全なアカウントを必要としますが、検証済みの実世界での身元は必要としません。
身元に紐付けられた登録: まず身元確認が行われ、その後FIDO認証情報が検証済みのアカウントに紐付けられます。
ステップアップまたは回復: サービスは、失われたオーセンティケーターの交換を許可する前に、身元を再検証するか、他の強力な証拠を使用します。

バインディングは明示的であるべきです。認証情報が追加されたときのアカウントと証明状態、それを承認したセッション、および後でリスクが発生した場合に再認証または身元情報の更新が必要になるかどうかを記録します。

アカウント回復と認証情報のライフサイクル

多くのフィッシング耐性のある展開では、回復がダウングレードされる箇所です。ユーザーがメールリンクや脆弱なサポートの質問を使用してすべてのFIDO認証情報を置き換えられる場合、攻撃者はその経路を標的にするでしょう。

完全なライフサイクルは以下をカバーします。

2番目のオーセンティケーターの追加。
登録された認証情報の命名と表示。
デバイスの紛失と不正使用の疑い。
アカウントを破壊せずに1つの認証情報を失効させること。
コード、別のオーセンティケーター、管理されたサポート、または身元確認による回復。
独立したチャネルを介したユーザーへの通知。
回復後のリスクの高い行動の遅延または制限。
認証情報セットを変更した人物と理由の記録。
侵害が報告される前に作成されたセッションの終了。

回復の保証は、オーセンティケーターを交換した場合の結果と一致するべきです。リスクの低いコミュニティアカウントと、資金を移動できる管理者は、同じ経路を必要としません。

FIDO2展開の評価方法

プロトコル検証

チャレンジの生成と期限、正確なオリジン検証、依拠当事者識別子ルール、署名検証、サポートされるアルゴリズム、UPとUVのポリシー、認証情報の関連付け、カウンター、バックアップフラグ、エラー処理をテストします。手書きのバイナリ解析よりも、保守されているサーバーライブラリを優先しますが、それが何を検証しているかを理解しておく必要があります。

オーセンティケーターのカバー範囲

プラットフォームおよびローミングオーセンティケーターを、サポートされているブラウザ、オペレーティングシステム、デバイス、トランスポート、エンタープライズポリシー、アクセシビリティ設定全体でテストします。認証情報の作成、サインイン、条件付きユーザーインターフェース、クロスデバイス使用、デバイス交換を含めます。

アカウントとセッションのセキュリティ

誰が認証情報を追加できるか、最近の認証が必要か、セッションがどのように昇格されるか、再認証がいつ発生するか、認証情報の変更が既存のセッションにどのように影響するかを確認します。

回復とサポート

紛失、デバイスの盗難、メールの侵害、SIMの変更、サポートのなりすまし、悪意のある家庭または職場へのアクセスに対してレッドチームテストを行います。攻撃者の抵抗力と正規ユーザーの完了の両方を測定します。

プライバシーと監視可能性

アテステーションとデバイスデータを、ポリシーが必要とする範囲に最小限に抑えます。依拠当事者間で安定した認証情報識別子を使用することは避けてください。WebAuthnのスコープはそれを防ぐように設計されています。機密性の高いクライアントデータを漏洩させずに、理由とプロセス結果をログに記録します。

FIDO2実装の一般的な間違い

署名はチェックするがコンテキストをチェックしない

サーバーがチャレンジ、オリジン、依拠当事者識別子、フラグ、アカウントバインディングを正確に検証しない場合、有効な署名だけでは不十分です。

すべてのパスキーを多要素認証と呼ぶ

サーバーは、ユーザー検証が行われたかどうか、および認証情報の特性がポリシーを満たしているかどうかを検証する必要があります。ユーザーの存在だけでは、ローカルユーザー検証とは異なります。

サイレントな認証情報追加を許可する

新しいオーセンティケーターを追加すると、アカウントのセキュリティが変更されます。適切な最近の認証または回復プロセスを要求し、ユーザーに通知し、イベントを記録します。

1つの認証情報のみをサポートする

1つの認証情報しかないアカウントは、回復が脆弱になり、より弱いフォールバックを奨励します。明確な管理と失効を伴う複数のオーセンティケーターを許可します。

パスワードを同等のフォールバックとして残す

パスワードが常にFIDOパスをバイパスできる場合、フィッシング耐性は優先されるボタンにのみ存在する可能性があります。リスクと移行段階に応じて、より弱いパスを制限または削除します。

サーバーセッションを無視する

FIDO2はログインプロセスを認証します。クッキーとトークンを保護し、認証後にセッションをローテーションし、機密性の高いアクションにはステップアップを要求し、侵害されたセッションを失効させます。

導入チェックリスト

リリース前に、以下を確認してください。

チャレンジが予測不能で、単一使用、短命であり、正しいセッションにバインドされているか。
オリジン、依拠当事者識別子、署名、アルゴリズム、フラグ、および認証情報の所有権が検証されているか。
保護された各アクションに対してUPおよびUVの要件が明示的であるか。
プラットフォーム、ローミング、同期、デバイスに紐付けられた、およびクロスデバイスのケースがサポートされているかテストされているか。
ユーザーが複数の認証情報を登録し、安全に命名、検査、失効できるか。
認証情報の追加と回復が適切な保証を要求し、通知を生成するか。
アテステーションの収集に定義された信頼、プライバシー、およびメタデータポリシーがあるか。
パスワード、ワンタイムコード、サポート、および身元回復のフォールバックが脅威モデル化されているか。
認証済みセッションとトランザクション承認が個別に保護されているか。
プロトコルライブラリ、ブラウザサポート、非推奨、およびセキュリティイベントに担当者がいるか。

FIDO2におけるDiditの役割

FIDO2は、認証情報が登録された後の認証を扱います。Diditは、本人確認、生体認証、およびバイオメトリック認証を通じて、関連する身元決定をサポートできます。公開されているバイオメトリック認証の価格はチェックあたり0.10ドルです。

チームは料金ページで現在のモジュール料金を確認できます。これらの製品がその説明からFIDO2を実装していると仮定すべきではありません。アーキテクチャ上のポイントは、身元確認、生体認証チェック、FIDO認証情報認証、アカウント回復、およびアプリケーション承認が異なる信頼決定であるということです。

よくある質問

FIDO2は何の略ですか？

FIDOはFast Identity Onlineの略です。FIDO2は、W3C WebAuthnとFIDO Alliance CTAPを組み合わせた公開鍵認証のための規格ファミリーです。

FIDO2はWebAuthnと同じですか？

いいえ、異なります。WebAuthnは依拠当事者とクライアントのAPIおよびデータモデルを定義します。FIDO2はWebAuthnとCTAPを含み、CTAPはクライアントプラットフォームとローミングオーセンティケーターを接続します。

パスキーはFIDO2認証情報ですか？

はい。パスキーはパスワードなしのサインイン用に設計された検出可能なFIDO認証情報です。これらは、対象となるデバイス間で同期することも、デバイスに紐付けられたままにすることもできます。

FIDO2はフィッシング耐性がありますか？

適切に検証されたFIDO2認証はフィッシング耐性があります。これは、認証情報が依拠当事者にスコープされており、アサーションがその検証コンテキストにバインドされているためです。ただし、脆弱な回復プロセスやすでに侵害されたセッションは、意図された保護をバイパスする可能性があります。

FIDO2は生体認証を使用しますか？

はい、ローカル生体認証を使用してオーセンティケーターをアクティブ化し、ユーザー検証を設定できます。依拠当事者は通常、生体認証テンプレートではなく、結果と暗号化されたアサーションを受け取ります。

FIDO2は個人の身元を検証しますか？

いいえ。登録された認証情報の制御を検証します。実世界での身元確認は、サービスが要求する場合、個別の登録または回復の決定です。

ユーザーがすべてのオーセンティケーターを紛失した場合、どうなりますか？

サービスは、アカウントのリスクに見合った回復ポリシーを必要とします。オプションには、別の登録済みオーセンティケーター、回復コード、管理された管理回復、または再度の身元確認などが含まれ、通知と回復後の制限が伴います。

主要参考文献

FIDO2は、再利用可能な検証秘密情報を、スコープされた公開鍵認証情報と新しい暗号プロセスに置き換えます。その価値は、依拠当事者が完全なコンテキストを検証し、認証情報のライフサイクルを管理し、セッションと機密性の高いアクションを保護し、回復にログインと同じセキュリティ上の注意を払う場合にのみ存続します。