パスキーとは?FIDO2で始める“本当の”パスワードレス認証徹底ガイド
パスワードをいくつも記憶し、定期的にリセットする…
そんな“認証の呪縛”を解き放つキーワードが「パスキー」です。FIDO2/WebAuthn に準拠した公開鍵暗号方式により、覚える文字列そのものを入力せずに安全なログインを実現します。
この記事では仕組みと最新動向、実装ガイドまでを一気通貫で解説し、明日からのパスワードレス移行をサポートします。
パスキーとは?公開鍵暗号で叶えるパスワードレス
パスキーはユーザー端末に秘密鍵を保持し、サービス側には対応する公開鍵だけを登録する認証方式です。ログイン時は公開鍵暗号のチャレンジレスポンスで本人性を判定し、パスワード入力や送信を排除します。
従来のパスワード運用に比べ、盗聴・フィッシングによる漏えいリスクが大幅に低減し、複雑なポリシー管理や定期変更の手間も不要です。
FIDO Alliance の2024年調査では62%の消費者(調査対象:米国・英国)がパスキーを認知しており、日本でも同水準の62%が認知しています。
これは“大半の人がまだ知らない新技術”ではなく、ユーザーが自然に受け入れつつある成熟フェーズに入りつつあることを示します。
FIDO2・WebAuthn の役割とフロー
FIDO2は、ブラウザとOS、認証器をつなぐ WebAuthn と、ブラウザ⇔認証器間通信を規定する CTAP2 から構成されます。
登録(create)フロー
サービスがチャレンジとユーザーIDを送信 → 認証器が鍵ペア生成 → 公開鍵&Credential IDをサーバー保存。
認証(get)フロー
サービスがチャレンジ送信 → 認証器が秘密鍵で署名 → サーバーが公開鍵で検証。
秘密鍵は端末を離れないため、漏えいしても即悪用されるパスワードとは決定的に異なります。
生体認証を用いる場合、多くのデバイスは ISO/IEC 30107‑3 に準拠した Liveness Detection を実装しています。ただしFIDO認証器において同規格は必須要件ではない点に注意が必要です。
【パスキー vs 他方式】メリット・デメリット比較
方式 | セキュリティ | ユーザー負担 | 運用コスト |
---|---|---|---|
パスワード | 漏えい・総当たり攻撃に弱い | 覚える負担大/リセット多 | ヘルプデスク対応が頻発 |
TOTP(二要素) | パスワードより高だがフィッシング被害あり | コード入力が手間 | アプリ同期・バックアップ管理 |
パスキー | 端末内秘密鍵で耐フィッシング◎ | 生体タップ一回 | 鍵同期でサポート削減 |
主要プラットフォーム対応状況と市場動向
iOS 17/macOS 14 ではSafariとiCloudキーチェーンがパスキー登録・同期を標準実装済み。
Android 9 以降(Google Play Services 23.50+)は Google Password Manager が鍵保管をサポートし、アプリ・Web双方で利用可能です。
Windows 11 22H2(KB5030310 適用)または 23H2 以降 はOS設定の「パスキー」画面で登録・削除を一元管理でき、Edge/Chrome から利用できます。
業界アナリストの予測によれば、2025年末までに上位1,000サイトの約25%がパスキーに対応すると見込まれています(iFeelTechが引用した専門家予測)。
参考:iFeelTech『Passkeys Authentication 2025 Guide』
参考:iFeelTech『Password Security Best Practices 2025』
プラットフォーム普及が進むにつれ、対応サービスは指数関数的に増加すると見込まれます。
また2025年5月1日のWorld Passkey Day では、参加企業のパスキー対応アカウント合計が150億件を超えた旨が発表され、採用拡大の勢いを裏付けました。
実装ガイド:サーバー側で押さえる三つのポイント
登録チャレンジの生成
ソルト付きランダム 32byte以上を推奨。短時間で失効させ、リプレイ攻撃を防ぎます。
永続化する項目
公開鍵・Credential ID・ユーザーID・signCountの四つ。signCountでクローン検知を行い、ズレがあれば再登録を促します。
プロトコルライブラリ
Java:Yubico WebAuthn Server
/ Node.js:SimpleWebAuthn
などを利用すると、challenge生成・署名検証をラップでき、実装コストを大幅に削減できます。
実装ガイド:フロントエンド最小サンプル
// 登録
const chal = await (await fetch('/register-challenge')).json();
chal.challenge = base64ToUint8(chal.challenge);
chal.user.id = base64ToUint8(chal.user.id);
const cred = await navigator.credentials.create({ publicKey: chal });
await fetch('/finish-register', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(toJSON(cred))
});
ログイン時は navigator.credentials.get()
を呼び出し、取得した署名を /finish-login
に送信します。
運用時のチェックリスト
- バックアップパスキー登録をオンボーディングで必須化(端末紛失に備える)。
- 未対応ブラウザ向けにパスワード+OTPのフォールバックを段階的に残す。
- signCount異常値・失敗率を監視し、侵害の兆候を早期検知。
- 本人確認レベルを満たすリカバリーフロー(公的身分証+Liveness など)を用意。
- TLS 1.3とHSTSを必須化し、証明書ピンニングで中間者攻撃を抑止。
Microsoft Authenticator と今後の移行スケジュール
MicrosoftはAuthenticatorアプリのオートフィル機能を2025年7月に停止、8 月以降はアクセス不可とすると発表しています。
参考:Microsoft Authenticator オートフィルの変更
代替としてパスキー管理を推奨しており、Windowsエコシステム全体がパスワードレスへ舵を切った形です。
OAuth 2.1完全ガイド|OAuth 2.0との違い・PKCE必須化と移行チェックリスト
まとめ:パスキー導入で得られる三つの成果
- フィッシング・漏えいの激減:秘密鍵が端末外に出ず、ユーザー入力もない。
- サポートコスト削減:パスワード忘れ→リセット対応が大幅に減少。
- UX向上:ワンタップ・ワンクリックでログイン完了。
技術的ハードルはライブラリとIDaaSの進化で年々低下しています。まずは開発環境でサンプルを動かし、バックアップパスキー登録のUXを体験してみてください。
“パスワードを入力する” という行為が博物館行きになる日は、もう遠くありません。