FIDO2とは？ 特徴やパスワードレス認証の仕組みについて解説

パスワードは、長らく「本人確認（認証）」の中心にある仕組みでした。しかし、クラウドサービスの普及やリモートアクセスの常態化により、パスワードに依存した環境は、攻撃者にとって狙われやすくなっています。漏えいしたパスワードの使い回し、フィッシングによる窃取、パスワードスプレー、認証情報の売買など、パスワードを起点とした攻撃が成立しやすい経路が増えているためです。

そこで注目されているのが、パスワードを前提にしない「パスワードレス認証」です。なかでもFIDO2（ファイド2）は、W3CのWebAuthnとFIDOアライアンスのCTAPを組み合わせ、Webサービスの認証を標準化された仕組みでパスワードレス化する枠組みです。サーバー側に“秘密（パスワード相当の機密）”を置かない設計を取れる点が、大きな特徴です。

この記事では、FIDO2の概要と特徴、FIDO1.0との違いに加え、WebAuthn／CTAPの役割、登録（初回に鍵を作る）と認証（ログイン時に署名で本人確認する）の流れ、導入・運用でつまずきやすい注意点まで、実務判断に使える粒度で整理します。

FIDO2とは

FIDO2は、FIDOアライアンスが策定する認証仕様群で、主にWebサービス（ブラウザ経由のログイン）を対象に、「公開鍵暗号方式」を用いた強固な認証を提供します。ポイントは、パスワードのような“共有秘密”をサーバー側に保存しないことです。サービス側（認証を提供する側）は、ユーザーごとの公開鍵など、検証に必要な情報のみを保持し、ユーザー側は秘密鍵を端末内（またはセキュリティキー内）に保持します。秘密鍵は外部に出ず、ログイン時にはチャレンジ（ランダム値）に対する署名を生成して提示し、サービス側が公開鍵で署名を検証することで本人性を確認します。

FIDO2は「パスワードを使わない」点が注目されがちですが、技術的な本質は「秘密鍵をユーザー側に閉じ込め、サービス側は検証可能な情報だけで認証を成立させる」点にあります。これにより、サーバー侵害によって“パスワード相当の秘密”が大量に漏えいするリスク構造を、根本から変えられます。

そもそもFIDO認証とは

FIDO認証とは、FIDOアライアンスが策定する認証規格・仕様群の総称です。FIDO1.0では、FIDO UAFやFIDO U2Fといった仕様が公開されていました。その後、Web認証の標準化とOS・ブラウザの対応を前提に、WebAuthn（W3C）とCTAP（FIDOアライアンス）を組み合わせた枠組みとして、FIDO2が広く使われるようになっています。

FIDO認証が広がった背景には、パスワードの管理負荷（忘却、使い回し、メモなど）と、攻撃側の手口の成熟（フィッシング、認証情報漏えいの流通、ボットによる自動試行）が同時に進んだことがあります。「ユーザーの努力」だけで維持できる安全性に限界が見え始めたため、仕組み側でリスクを下げる方向へとシフトしてきました。

FIDO認証の全体像については、以下も参考になります。

→「FIDO認証とは？ パスワードレスを実現する仕組みとメリットなど」

パスワードレス認証とは

パスワードレス認証とは、パスワード入力を前提としない認証方式・運用の総称です。実装は複数あり、たとえば以下のような要素を組み合わせて実現します。

• 所持要素：端末（スマートフォン、PC、セキュリティキー）を持っていること
• 生体要素：指紋や顔など（端末内で本人確認に使う）
• 知識要素：PINやパターンなど（端末のローカル解除に使われることが多い）

ここで重要なのは、生体情報そのものをサービスへ送信するのではなく、端末内で本人確認を行い、その結果として秘密鍵で署名できる状態を作る設計が一般的である点です。FIDO2は、この考え方をWeb認証の標準として提供します。

なぜパスワードは「侵入の糸口」になりやすいのか

パスワードが問題になりやすい理由は、大きく「攻撃者が狙いやすい構造」と「運用が破綻しやすい現実」が重なるためです。

攻撃者が狙いやすい構造

• 共有秘密である：ユーザーとサービスの双方が“同じ秘密”を扱うため、盗まれるとそのまま利用されます。
• フィッシングに弱い：ユーザーが入力した瞬間に、攻撃者が認証情報を取得できます。
• 漏えいの連鎖が起きる：流出した認証情報は再利用されやすく、別サービスへの侵入に波及します。
• ボットで試行できる：パスワードスプレーのように、少数の候補を多数のアカウントに試す攻撃が成立します。

運用が破綻しやすい現実

• 人は強いパスワードを大量に覚えられない：結果として、使い回しや単純化が起きがちです。
• リセットが“抜け道”になりやすい：アカウント回復（メール、SMS、本人確認）が弱いと、そこが侵入口になります。
• 対策の副作用：複雑な要件や頻繁な変更は、メモや共有、問い合わせ増加など、別のリスクを生みがちです。

この「構造」と「現実」の両方を変えない限り、パスワード環境を守り切るのは難しくなります。FIDO2は、認証の成立条件そのものを変えることで、攻撃が成立する確率を下げるアプローチです。

FIDO1.0からFIDO2への進化

FIDOは、大きくFIDO1.0とFIDO2に分けられます。ここでは、FIDO2が登場した背景と、FIDO1.0との違いを整理します。

FIDO2登場の背景

FIDO2（パスワードレス認証）が求められている背景には、次のようなパスワード運用の課題があります。

・ID／パスワードの流出や盗取
・パスワード管理の破綻（使い回し、メモ、共有、忘却）
・ユーザー体験の悪化（入力やリセットの手間）

パスワード認証は、ユーザー側とサーバー側の両方が“秘密”を扱う構造になりやすく、どこかが破られると不正ログインが成立します。また、SaaSの利用が増えるほど、運用上の歪み（使い回し、権限の放置、回復手順のばらつき）が生じやすくなります。こうした課題を根本から減らすために、「パスワードを前提にしない」設計が求められ、FIDO2が広く採用される土台が整ってきました。

FIDO1.0とFIDO2の違い

FIDO1.0には、「FIDO UAF」と「FIDO U2F」の2種類がありました。

・FIDO UAF：主に生体認証などを使ったパスワードレス認証を想定したプロトコル
・FIDO U2F：主にセキュリティキーなどを用いた強固な二要素認証（2FA）を想定したプロトコル

FIDO2は、Webサービスでの利用を強く意識し、ブラウザ標準API（WebAuthn）と、認証器との連携プロトコル（CTAP）で構成されます。「FIDO2では専用ハードウェアが不要」と説明されることがありますが、これは条件付きの表現です。FIDO2は、専用プラグインや独自実装に頼らず、OS・ブラウザの標準機能として扱えるようになった一方で、認証器（Authenticator）自体は必要です。ただし、その認証器がスマートフォンやPCに内蔵されているケースが多く、結果として追加機器が不要になる場合が増えています。

FIDO2の特徴

FIDO2の特徴は、単に「パスワードをなくす」ことだけではありません。実務では、どのリスクがどの層で低減されるのかを理解したうえで、導入範囲や併用策を設計することが重要です。

パスワードを使わずに認証できる

FIDO2では、ユーザーがパスワードを入力しない認証が可能です。ユーザー操作としては、端末のロック解除（指紋・顔・PINなど）を行い、端末内の秘密鍵で署名してログインが完了する形が一般的です。入力型の認証情報を攻撃者へ渡しにくい構造になるため、フィッシングや漏えい認証情報の再利用に対して強くなります。

サーバー側に「秘密」を保存しない

FIDO2でサービス側が保持するのは、基本的に公開鍵などの検証情報です。仮にサービス側が侵害されても、公開鍵だけでは署名は作れません。パスワードのハッシュが漏えいした場合のように、「それ自体が不正ログインの材料になる」度合いが低くなります。

ただし、これが「サーバー侵害でも何も起きない」という意味ではありません。アカウント情報、個人情報、セッション管理、権限設計が弱い場合には、別経路で被害が生じる可能性があります。FIDO2は、あくまで“認証の入口”の強度を高める中核技術として捉えるのが現実的です。

既存デバイスを認証器として流用できる場合が多い

FIDO2は主要OSと主要ブラウザで広く対応しており、スマートフォンやPCに内蔵された認証機能（指紋・顔、TPMやセキュアエンクレーブ相当の保護領域など）を使えるケースが増えています。外付けのセキュリティキーを使えば、端末をまたいで利用できる運用も可能です。これにより、導入コストやユーザーの負担を抑えつつ、認証強度を高めやすくなっています。

FIDO2によるパスワードレス認証の仕組み

FIDO2を理解するうえで重要なのは、ログインの瞬間だけでなく、「登録（初回に鍵を作って紐付ける）」と「認証（署名して本人確認する）」の2段階で成立している点です。さらに、ブラウザとサーバー間はWebAuthn、クライアントと認証器間はCTAPという役割分担で成り立ちます。

FIDO2の構成要素

FIDO2を実務の観点で分解すると、主に次の4つで整理できます。

• クライアント（ブラウザ／OS）：WebAuthn APIを実行し、認証器の利用を仲介します。
• Authenticator（認証器）：秘密鍵を保持し、ユーザーのローカル本人確認（指紋・顔・PINなど）を通したうえで署名を生成します。
• サービス（Relying Party）：ユーザーがログインしたいWebサービス本体です。
• FIDOサーバー（WebAuthn検証コンポーネント）：WebAuthnの登録・認証を処理し、鍵情報の管理や署名検証を行います（実装としては、サービス内に内包される場合もあります）。

「FIDOサーバー」という言葉は、製品や構成によって呼び方が揺れやすい点に注意が必要です。重要なのは、WebAuthnのチャレンジ生成、登録情報の検証・保存、署名検証を正しく実装・運用する責務が、どこかに確実に存在することです。

WebAuthn（Web Authentication）

WebAuthnは、Webサービス向けの認証を標準化する仕様で、ブラウザが提供するWeb APIとして利用されます。サービス側（Relying Party）がチャレンジや許可パラメータを提示し、ブラウザが認証器を呼び出して、登録情報（公開鍵など）や署名応答を受け取る流れを規定しています。

WebAuthnの実務上の重要点は、資格情報がRelying Party（オリジン）にスコープされることです。登録した資格情報は、そのRelying Partyに属するオリジンからしか利用できないため、偽サイトへ誘導されても、正規サイトと同じ手順の認証は成立しにくくなります。

CTAP（Client To Authenticator Protocol）

CTAPは、クライアント（ブラウザ／OS）と認証器の間で情報をやり取りするためのプロトコル仕様です。代表例として、USB／NFC／BLEのセキュリティキー（ローミング認証器）と、PCやスマートフォンを連携させる際に使われます。CTAPはWebAuthnと組み合わせてFIDO2を構成する要素の1つで、CTAP1／CTAP2という世代があります。FIDO2では主にCTAP2を前提に、より柔軟なパスワードレスや拡張要素に対応します。

認証器の種類と、設計に効く違い

FIDO2の導入設計では、認証器を大きく2種類に分けて考えると判断しやすくなります。

• プラットフォーム認証器：端末に内蔵される認証器（スマートフォン、PC内蔵）。ユーザー体験が良く、配布が不要な場合が多い一方、端末紛失や機種変更時の移行設計が重要になります。
• ローミング認証器：外付けのセキュリティキーなど。端末をまたいで使いやすく、管理ポリシーを適用しやすい一方、配布や紛失時の対応、予備の確保が運用上の課題になります。

どちらが正解というよりも、対象業務（特権ID、在宅勤務、外部委託、共用端末の有無）や、運用体制（貸与端末管理、ヘルプデスク、資産管理）に合わせて設計することが重要です。

FIDO2の認証手順（登録とログインを分けて理解する）

FIDO2は、「鍵を作って紐付ける（登録）」と「署名して本人確認する（認証）」で流れが異なります。ここを分けて理解すると、用語や挙動の誤解が減ります。

1. 登録（初回：鍵ペアを作ってサービスに登録する）

1. ユーザーがサービスで「FIDO2で登録」を開始します。
2. サービス（Relying Party）がチャレンジと登録条件を提示します（WebAuthnの登録要求）。
3. ブラウザが認証器を呼び出し、ユーザーは端末のローカル本人確認（指紋・顔・PINなど）を実施します。
4. 認証器が鍵ペア（秘密鍵・公開鍵）を生成し、公開鍵などの登録情報を、ブラウザ経由でサービスへ返します。
5. サービスは登録情報を検証し、ユーザーアカウントに公開鍵などを紐付けて保存します。

登録時に「秘密鍵」はユーザー側に残り、サービス側へ送られません。サービス側に保存されるのは、公開鍵などの検証情報です。

2. 認証（ログイン：チャレンジに署名して本人確認する）

1. ユーザーがサービスへログインを要求します。
2. サービスがチャレンジ（ランダム値）などを提示します（WebAuthnの認証要求）。
3. ブラウザが認証器を呼び出し、ユーザーは端末のローカル本人確認を行います。
4. 認証器は秘密鍵でチャレンジなどに対する署名を生成し、ブラウザ経由でサービスへ返します。
5. サービスは、保存してある公開鍵で署名を検証し、正しければログインを許可します。

ここで重要なのは、FIDO2が「暗号化して送る」「復号できたら本人」という仕組みではなく、チャレンジに対する署名を公開鍵で検証する仕組みである点です。通信経路上にパスワードや生体情報が流れないことに加え、オリジンに紐づく設計により、フィッシングに強い認証の土台が作られます。

導入・運用で押さえるべき注意点

FIDO2は強力ですが、「導入すれば終わり」というものではありません。特に企業や組織で導入する場合、回復（リカバリ）と端末ライフサイクル、併用方針を決めておかないと、利便性と安全性が崩れやすくなります。

アカウント回復（リセット）が弱いと、全体が弱くなる

パスワードレス化しても、アカウント回復がメールのみ、SMSのみといった弱い設計だと、攻撃者はそこを狙います。FIDO2導入時は、「登録の再実行」「端末紛失時の本人確認」「ヘルプデスク運用」まで含めて、回復手段の強度をそろえることが重要です。

端末紛失・機種変更・退職時の扱いを最初に決める

プラットフォーム認証器を中心にすると、端末の紛失や交換が運用イベントになります。予備手段（複数認証器の登録、予備キーの配布、管理者による復旧フロー）を用意し、退職や委託終了時には、認証器登録の棚卸しや無効化が確実に回るようにします。

適用範囲（どのアカウントに必須にするか）を決める

全社一律が難しい場合でも、優先順位は付けられます。たとえば、特権ID、経理や人事、外部公開SaaS、リモートアクセス、メール基盤など、侵害時のインパクトが大きい領域から必須化するのが一般的です。段階導入であっても、「例外の管理」と「例外の期限」を設計しないと、抜け道が恒常化します。

「フィッシング耐性」は万能ではない

FIDO2はフィッシングに強い設計ですが、端末自体が侵害される、利用者が意図せず登録を許可してしまう、セッション管理や権限設計が弱い、といった別要因で被害が生じる可能性は残ります。FIDO2は認証の中核でありつつ、端末防御、ログ監視、条件付きアクセス、特権管理などと組み合わせて、侵害後の被害拡大を抑える設計が重要です。

まとめ

FIDO2は、公開鍵暗号を用いてサーバー側に“秘密”を置かない構造を作り、Web認証をパスワードレス化するための標準的な仕様群です。FIDO1.0からの進化点は、WebAuthnとCTAPを軸に、OSやブラウザの標準として広く実装され、既存デバイスを認証器として活用しやすくなった点にあります。

一方で、導入を成功させるには、「登録と認証の仕組み」を正しく理解し、アカウント回復、端末ライフサイクル、適用範囲、例外管理まで含めて設計することが欠かせません。FIDO2を中核に据え、運用と技術の両面で“破綻しにくい認証”を構築することが、これからの認証基盤の品質を左右します。