FIDO2/WebAuthn は、パスワードの代わりに端末の中の秘密鍵で署名してログインする仕組みで、パスキーもこの上に成り立っています。サーバーには公開鍵しか保存されず、署名は登録したサイトのドメインに結び付くため、パスワードの使い回しやフィッシングに強いのが特徴です。この記事では、仕組み・用語・導入時の注意点を整理し、WordPress で使う場合の選択肢と、締め出されないための準備までを説明します。
FIDO2・WebAuthn・CTAP・パスキーの関係
似た言葉が多いので、最初に関係を整理します。
- FIDO2：FIDO Alliance と W3C が進めるパスワードレス認証の規格群の総称です。次の2つで構成されます。
- WebAuthn（Web Authentication）：ブラウザと Web サイトの間の API を定めた W3C の仕様です。JavaScript の
navigator.credentials.create()（登録）とnavigator.credentials.get()（認証）を使います。 - CTAP（Client to Authenticator Protocol）：ブラウザや OS と、USB・NFC・Bluetooth でつながるセキュリティキーなどの「認証器」との間の通信を定めた FIDO Alliance の仕様です。
- パスキー（Passkey）：WebAuthn の認証情報のうち、ユーザー名を入力しなくても候補として呼び出せる形式（discoverable credential）を、一般向けに呼びやすくした名前です。Apple・Google・Microsoft などのプラットフォームや、パスワード管理ツールが対応しています。
認証器には、端末に内蔵されたプラットフォーム認証器（Windows Hello、Touch ID/Face ID、Android の画面ロックなど）と、持ち運べるローミング認証器（USB/NFC のセキュリティキー）があります。
ログインの流れ：何がサーバーに送られるのか
WebAuthn では、登録と認証の2つの手続きがあります。
登録では、サイト（仕様では Relying Party、RP と呼びます）がランダムな値（チャレンジ）とサイトの識別子（RP ID、通常はドメイン名）をブラウザに渡します。認証器はそのサイト専用の鍵ペアを作り、秘密鍵は認証器の中に残したまま、公開鍵と認証情報の ID をサイトに返します。サイトはこれをユーザーに紐付けて保存します。
認証では、サイトが新しいチャレンジを渡し、認証器がユーザーの確認（指紋・顔・PIN など）を行ったうえで秘密鍵で署名します。サイトは保存してある公開鍵で署名を検証し、正しければログインさせます。
この流れから、次の性質が出てきます。
- サーバーにパスワードに相当する秘密が無い：保存しているのは公開鍵なので、データベースが漏れても、それだけでログインに使われることはありません。
- 生体情報は端末の外に出ない：指紋や顔の照合は端末内で行われ、サイトに届くのは「確認した」という結果と署名だけです。
- フィッシングに強い：ブラウザが今開いているドメインを認証器に伝え、鍵はそのドメイン（RP ID）に結び付いているため、見た目をまねた偽サイトでは署名が得られません。
導入前に知っておきたい制約
便利な一方で、運用面で考えておくべき点もあります。
- HTTPS が前提：WebAuthn はセキュアコンテキストでしか動きません（開発時の localhost は例外として扱われます）。また RP ID はサイトのドメインに対応するため、ドメインを変えると登録済みの認証情報が使えなくなることがあります。サイト移転を予定しているなら、移転後に再登録してもらう手順を用意します。
- 同期型と端末固定型の違い：多くのパスキーはクラウド経由で同じアカウントの端末間に同期されます。端末をなくしても復元しやすい反面、そのクラウドアカウントの保護が重要になります。セキュリティキーのように端末から出ない鍵は持ち出しにくい一方、なくすと使えなくなります。
- 端末を失ったときの復旧手段：認証器を2つ以上登録してもらう、バックアップコードを発行する、管理者が本人確認のうえで再登録させる、といった手段を最初から決めておきます。
- 対応状況は変わり続ける：ブラウザ・OS・パスワード管理ツールの対応や画面の表記は更新が多い分野です（2026年10月現在も変化が続いています）。利用者向けの案内は、具体的なボタン名より「OS の画面に従って指紋や PIN で確認する」といった表現にしておくと古くなりにくくなります。
自作するなら：サーバー側で検証すべきこと
WebAuthn の検証は、署名形式・エンコード（CBOR）・各種フラグの確認など注意点が多く、ゼロから実装するのはおすすめしません。PHP なら web-auth/webauthn-lib や lbuchs/WebAuthn のような既存のライブラリを使い、それでも次の点は自分のコードで確認できるようにしておきます。
- チャレンジはサーバーで生成し、1回使ったら破棄する（使い回すとリプレイの余地が生まれます）
- 署名の検証に加えて、origin（オリジン）と RP ID が自分のサイトと一致するか
- ユーザー確認（UV）を求める設定にしたなら、応答のフラグで実際に確認が行われたか
- 署名カウンターを保存し、不自然な値の戻りがないか（同期型パスキーでは 0 のままのこともあるため、扱いはライブラリの方針に合わせます）
WordPress 上で実装する場合は、登録・削除の処理に nonce と権限チェックを入れ、ユーザー入力はサニタイズし、表示はエスケープします。ログイン失敗の回数制限も、パスワードログインと同じように考えます。
WordPressでパスワードレス認証を使う方法
WordPress コアには、パスキーでログインする機能は標準では入っていません（2026年10月現在）。使う場合はプラグインで追加します。代表的な選択肢は次のとおりです。
- Two-Factor：WordPress.org で公開されている2要素認証プラグインで、コア貢献者が開発に関わっています。TOTP やバックアップコードなどを扱え、WebAuthn は追加プラグイン（Two Factor Provider: WebAuthn など）で対応する形です。パスワードを残したうえで2要素目にセキュリティキーを使う構成になります。
- WP-WebAuthn：WebAuthn によるログインを追加するプラグインで、設定によってはパスワードを使わないログインも選べます。
- 総合セキュリティプラグインの機能：Solid Security など、セキュリティプラグインの一部にパスキー対応が含まれているものがあります。無料版と有料版のどちらに含まれるかは変わることがあるため、公式の説明で確認してください。
どれを選ぶ場合も、最終更新日・対応している WordPress のバージョン・サポートフォーラムの状況を見て、更新が続いているものを選びます。導入はステージング環境で試し、本番に入れる前にバックアップを取ります。
いきなり全員をパスワードレスにしない
最初は管理者だけ、または希望者だけに使ってもらい、パスワードと併用できる状態から始めるのが安全です。全ユーザーに強制するのは、復旧手順が回ることを確認してからにします。
締め出されたときの戻り方を用意する
認証プラグインの不具合や設定ミスで管理者がログインできなくなった場合、FTP や SFTP、サーバーのファイルマネージャーで wp-content/plugins/ の該当プラグインのフォルダ名を変えると、そのプラグインは無効になります。この方法で入れることを、導入前に一度確かめておくと安心です。WP-CLI が使える環境なら wp plugin deactivate プラグイン名 でも無効化できます。
個人データとプライバシーポリシー
保存されるのは主に公開鍵・認証情報の ID・登録日時などで、生体情報そのものは含まれません。それでもユーザーに紐付くデータなので、プライバシーポリシーには「ログインのために認証器の公開鍵などを保存する」ことを書き、退会時には削除されるかどうかも確認しておきます。
まとめ
- FIDO2 は WebAuthn（ブラウザとサイト）と CTAP（ブラウザと認証器）で構成され、パスキーはその認証情報を使いやすくしたものです。
- サーバーには公開鍵だけが保存され、署名はドメインに結び付くため、漏えいとフィッシングに強くなります。
- HTTPS が前提で、ドメイン変更・端末紛失への備え（複数登録・バックアップコード）が運用の鍵になります。
- WordPress ではプラグインで導入し、まず一部のユーザーで試し、プラグインを FTP で無効化する戻り方を確かめておきます。