FIDO認証完全ガイド：WebAuthnとパスキーで実現するパスワードレス認証の仕組みと導入ポイント
エバープレイ編集部イントロダクション
パスワードの使い回しやフィッシングによる情報漏洩が後を絶たない現代において、より安全で使いやすい認証方式が求められています。FIDO（Fast IDentity Online）認証は、その解決策として注目を集める標準群です。本稿では、FIDOの目的・構成要素・動作原理・利点や限界、導入時の実務的ポイントまでを丁寧に解説します。
FIDOとは何か
FIDOはFIDO Allianceという業界団体が策定する認証規格群の総称で、パスワードに依存しない公開鍵暗号方式を使った強固でフィッシング耐性の高い認証を実現します。主要な流れとしては、サーバー側にパスワードを保存するのではなく、ユーザー端末上の「オーセンティケータ」が生成した公開鍵を登録し、以後その秘密鍵でチャレンジに署名することで本人性を示します。
主要技術要素（FIDO U2F / UAF / FIDO2 / WebAuthn / CTAP）
- U2F（Universal 2nd Factor）：GoogleやYubico等が中心に提唱した「第2要素」用の規格。物理キー（USB/NFC/BLE）を用いる例が多い。
- UAF（Universal Authentication Framework）：モバイル端末の生体認証などを主眼に置いたパスワードレスのアプローチ。
- FIDO2：WebAuthn（W3C）とCTAP（FIDO Alliance）を組み合わせた最新の仕様群。Webブラウザとサーバー間の標準APIが定められ、パスワードレスや2要素をブラウザで統一的に扱える。
- WebAuthn：W3Cが標準化したウェブAPI。Webサイト（Relying Party）が認証器の登録・呼び出しを行うための仕様。
- CTAP（Client to Authenticator Protocol）：ブラウザ（クライアント）と外部オーセンティケータ（物理キーなど）間の通信プロトコル。CTAP1はU2F互換、CTAP2はFIDO2に対応。
認証の基本的な流れ：登録（登録/Registration）と認証（認証/Assertion）
大きくは2段階で動きます。まず登録時に、オーセンティケータが公開鍵/秘密鍵ペアを生成し、公開鍵＋メタデータ（attestation：認証器の種類や製造証明）をサーバーに送ります。サーバーは公開鍵をユーザーアカウントに紐付けて保存します。認証時はサーバーがランダムなチャレンジを送り、オーセンティケータが秘密鍵で署名して応答。サーバーは登録済みの公開鍵で署名を検証し、本人性を確認します。
オーセンティケータの種類とユーザー検証
- プラットフォーム型（Platform）：端末内蔵の認証器。例：Windows Hello、macOSのTouch ID/Face ID、AndroidのFingerprint/Keystore。
- ローミング型（Roaming / External）：USB/NFC/Bluetooth接続の外部デバイス（YubiKey等）。複数端末で使える。
- ユーザー検証方式：ユーザー存在確認（user presence：ボタン押下等）とユーザー検証（user verification：PINや生体認証）。WebAuthnはこれらを区別して扱います。
アテステーション（attestation）とプライバシー
アテステーションはオーセンティケータの製造情報や証明書を通じて、正当な認証器であることを示す仕組みです。これによりサーバーはデバイスの信頼レベルを判断できますが、同時にデバイス固有の識別子が追跡に使われる懸念も生じます。WebAuthnではアテステーションの扱い方（none / indirect / direct）を選べるほか、プライバシー保護のために匿名化技術（例：ECDAA）を用いることも可能です。
なぜFIDOは安全なのか（利点）
- 公開鍵暗号に基づくため、サーバー側に秘密情報（パスワードや共有シークレット）を保存しない。流出リスクが大幅に減る。
- フィッシング耐性：チャレンジは発行元のドメイン等に紐づくため、攻撃者サイトで正規サイトの鍵が使えない。
- 多様なユーザービリティ：生体認証やPIN併用で高速・直感的なログインが可能。
- 標準化され幅広いエコシステムに対応：主要ブラウザやOSがサポート。
限界とリスク
- 端末紛失・破損時のアカウント復旧策を用意する必要がある（リカバリキー、別の認証器の登録、アカウント回復フロー等）。
- ローカルな端末が完全に乗っ取られた場合（マルウェアや物理的侵害）、生体認証やPINが無効化されるリスクはゼロではない。
- 導入・運用コスト：既存システムとの統合やユーザー教育が必要。
実装時の実務的ポイント
- まずWebAuthn対応をサーバー側に実装する。主要言語向けのライブラリ（Java, Python, Go, Node.js等）が充実している。
- アテステーション方針を決める：厳格にデバイスを判定するのか、プライバシー重視で「none」にするのか。
- UX設計：初回登録時の導線、代替ログイン（メールリンク、SMSは弱いので慎重に）、リカバリ手段の提示を明確に。
- 監査・ロギング：認証イベントやアテステーション失敗時のログを残し、異常検知を行う。
- コンプライアンス：金融等の分野ではNIST等のガイダンス（フィッシング耐性の要件）を確認する。
普及状況と「パスキー（Passkeys）」の登場
近年、主要プラットフォーム（Apple, Google, Microsoft）やブラウザがFIDO/WebAuthnを推進しており、「Passkeys（パスキー）」という商用呼称も普及しています。パスキーはFIDO2/WebAuthnベースのパスワードレスな認証情報で、クラウド同期（iCloud Keychain等）により端末間の移行や復旧を容易にする動きが進んでいます。多くの大手サービスがパスキー対応を進めており、パスワードレス移行は加速しています。
まとめ
FIDO認証は公開鍵基盤を活用し、フィッシング耐性やサーバー側のリスク低減を実現する現代的な認証方式です。WebAuthn/CTAPから成るFIDO2はブラウザやOSで標準サポートされつつあり、パスワードレスや第2要素として多くの利点を提供します。ただし、導入にはアカウント復旧策、UX設計、運用体制の整備が不可欠です。適切に設計・実装すれば、組織とユーザー双方にとって大きなセキュリティ向上と利便性向上をもたらします。
参考文献
- FIDO Alliance（公式サイト）
- FIDO2（FIDO Alliance）
- Web Authentication: W3C Recommendation
- MDN Web Docs: Web Authentication API
- Can I Use — Web Authentication（ブラウザ対応状況）
- NIST SP 800-63B: Digital Identity Guidelines — Authentication and Lifecycle Management
- Apple: Use passkeys
- Google: FIDO & WebAuthn
投稿者プロフィール
