WebAuthnとは？パスキー認証を実装する仕組みと登録・認証フロー・RP実装の要点

WebAuthn（Web Authentication API）は、パスキーによるパスワードレス認証をWebサービスに組み込むためのW3C標準仕様です。ブラウザのJavaScript APIとしてnavigator.credentials.create()とnavigator.credentials.get()の2つの入口を持ち、公開鍵暗号でログインを成立させる仕組みです。この記事では、credential登録から認証までのフロー、attestation・assertionをサーバ側（RP）で検証する手順、authenticatorSelectionやライブラリ選定の設計判断、対応ブラウザとLevel 3の新機能までを、自社サービスにパスキー対応を実装する開発者向けに整理します。パスキーという概念そのものの説明や経営側の導入判断は、別記事の判断ハブに分離しています。

まとめ：WebAuthnはパスキー実装の標準APIとRP検証の要点

WebAuthnは、W3Cが標準化した公開鍵ベースの認証APIで、FIDO2を構成する2つの仕様のうちブラウザ側を担います。サーバは公開鍵だけを保存し、秘密鍵は認証器から出ないため、パスワードのように漏えいした資格情報を使い回される余地がありません。オリジンを検証に組み込む設計により、偽サイトでは署名自体が成立しない耐フィッシング性を持ちます。

実装の骨格は2本のフローに集約されます。登録ではnavigator.credentials.create()で認証器に鍵ペアを作らせ、返ってきたattestationをサーバで検証して公開鍵とcredential IDを保存する流れです。認証ではnavigator.credentials.get()で署名（assertion）を取得し、challenge・origin・rpIdHash・flagsを確認したうえで保存済み公開鍵により署名を検証します。この検証ロジックは自作せず、SimpleWebAuthnなどの実績あるライブラリに任せるのが定石です。会員向けサービスのログインを持つなら採用する価値が高く、逆にアカウント回復経路を設計できないまま全面移行するのは危険、というのが本記事の結論です。

WebAuthnの定義とFIDO2・CTAPの構成およびパスキーとの関係

実装に入る前に、WebAuthn・FIDO2・CTAP・パスキーという用語の層を分けておくと、以降のフローが読みやすくなります。名前が似ているぶん、ここの混同が設計ミスの入口になりがちです。

W3C勧告の資格情報APIという位置づけとFIDO2・CTAPの役割分担

WebAuthnは、W3Cが「Web Authentication」として勧告した仕様で、ブラウザのCredential Management APIを公開鍵資格情報へ拡張したものです。Level 1が2019年3月、Level 2が2021年4月に勧告となり、Level 3は2026年5月26日版の勧告候補として策定が進んでいます（2026年7月時点）。仕様上の登場人物は、認証を要求するWebサービス＝RP（Relying Party）、仲介するブラウザ（クライアント）、鍵を保持する認証器（Authenticator）の3者です。

FIDO2は、このWebAuthnとCTAP（Client to Authenticator Protocol）を合わせたプロジェクトの総称になります。WebAuthnがJavaScriptからブラウザまで、CTAPがブラウザからセキュリティキーやスマートフォンといった外部認証器までの通信を受け持つ分担です。RP実装者が直接書くのはWebAuthnの層だけで、CTAPはブラウザとOSが処理します。FIDO規格全体の成り立ちや認証器の内部機構はFIDO認証とは？仕組み・FIDO2/パスキー・導入判断までを解説で扱っているため、本記事はRP実装の視点に絞ります。

パスキー（同期型の発見可能クレデンシャル）とWebAuthnの関係整理

パスキーは、WebAuthnで作られる資格情報のうち、発見可能クレデンシャル（discoverable credential）をiCloudキーチェーンやGoogleパスワードマネージャーなどが複数端末へ同期する運用形態を指す呼び名です。API自体はパスキー登場前のWebAuthnと同じで、RP側の実装差分は「credential IDを事前に指定しなくてもログインできる」よう発見可能クレデンシャルを要求する設定に集約されます。

同期される性質は利便性と引き換えに、署名カウンタが機能しにくくなるなど検証設計への影響もあります（後述）。パスキーそのものの仕組み・パスワードとの違い・企業としての導入判断はパスキー認証とは？仕組み・パスワードとの違い・企業の導入判断を解説が判断ハブです。本記事は「導入すると決めた後、どう実装するか」を受け持ちます。

パスキー登録フローの実装：create()呼び出しとサーバ検証の流れ

登録（Registration）は、ユーザーのアカウントに新しい鍵ペアを紐づける工程です。サーバでオプションを組み立て、ブラウザでnavigator.credentials.create()を呼び、返ってきた結果をサーバで検証して保存する、という往復で構成されます。

challenge生成からcreate()呼び出しまでのオプション設計手順

登録の起点はサーバです。暗号学的乱数で16バイト以上のchallengeを生成し、セッションに紐づけて保持したうえで、PublicKeyCredentialCreationOptionsとしてブラウザへ渡します。フロントはこれを引数にnavigator.credentials.create()を呼ぶだけで、OSの生体認証ダイアログまでの一連のUIはブラウザが表示します。オプションで実装者が判断する項目は次のとおりです。

1. rp：rp.idにサービスのドメイン（例：example.co.jp）を指定する
2. user：user.idは64バイト以内のランダム値にし、メールアドレス等の個人情報を入れない
3. challenge：リクエストごとに使い捨てる。再利用するとリプレイ攻撃の入口になる
4. pubKeyCredParams：ES256（alg:-7）を先頭に、RS256（alg:-257）を後置する並びが標準的
5. authenticatorSelection：発見可能クレデンシャルの要否と検証要件（設計判断は後述の章）

rp.idは後の認証で検証されるrpIdHashの元になるため、サブドメイン構成をまたぐならどの階層で発行するかを最初に決めておきます。ここを後から変えると、発行済みクレデンシャルが一致しなくなり作り直しになります。

attestation検証とサーバ側で保存する公開鍵・credential IDの管理

create()が返すPublicKeyCredentialには、clientDataJSONとattestationObjectが含まれます。サーバはclientDataJSONのtypeが登録を示す値であること、challengeが発行値と一致すること、originが自サービスのURLであることをまず確認します。次にattestationObject内のauthenticatorDataからrpIdHashとflagsを検証し、公開鍵とcredential IDを取り出す流れです。

attestation（認証器の出自証明）は、既定値の「none」で受けるのが現在の実務標準です。認証器の機種を制限したい金融・行政系の要件がない限り、証明書チェーンの検証コストに見合いません。検証を通過したら、ユーザーIDに対して credential ID・公開鍵・署名カウンタ初期値・作成日時を保存します。1ユーザーに複数クレデンシャルを持てるテーブル設計にしておくと、端末追加やセキュリティキー併用にそのまま対応できます。

認証フローの実装：get()による署名取得とサーバ側の検証項目

認証（Authentication）は、保存済み公開鍵に対応する秘密鍵の所持を署名で証明する工程です。登録と同じくchallengeの往復で構成され、サーバ検証の網羅性がそのまま安全性を決めます。

assertion取得とパスキー自動入力（conditional UI）の実装

サーバが新しいchallengeを発行し、ブラウザがnavigator.credentials.get()を呼ぶと、認証器はユーザー確認のうえ秘密鍵で署名したassertionを返します。発見可能クレデンシャルを使う場合、allowCredentialsを空にすればユーザー名の入力なしで認証器側がアカウントを提示します。

ログインUIで効くのがconditional mediationです。get()にmediationとしてconditionalを指定し、ユーザー名入力欄のautocomplete属性にwebauthnを含めると、フォーム表示と同時にパスキーが自動入力候補として提示されます。モーダルを強制しないため既存のパスワードフォームと共存でき、移行期のUIとして現行のChrome・Safari・Edgeで動作します。対応可否はPublicKeyCredential.isConditionalMediationAvailable()で実行時に判定してから有効化してください。

署名検証でサーバが確認するorigin・rpIdHash・flags・署名カウンタ

assertion検証の順序は仕様で決まっており、崩してはいけません。clientDataJSONのtype・challenge・originの確認、authenticatorDataのrpIdHashが自サービスのrp.idのSHA-256と一致するかの確認、flagsのUP（ユーザー存在）とUV（ユーザー検証）の確認を経て、最後に保存済み公開鍵で署名を検証します。originとrpIdHashの照合が耐フィッシング性の実体で、偽ドメインで取得した署名はここで必ず落ちます。

署名カウンタ（signCount）はクローン検知のための単調増加値ですが、同期型パスキーでは常に0を返す実装が主流のため、増加しないことを即エラーにすると正規ユーザーを弾きます。カウンタが減少したときだけ警告ログを残す運用に留めるのが現実的です。検証を通過した後のセッション確立はWebAuthnの範囲外で、セッションIDやトークンの設計はJWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いを実装視点で解説で整理しています。

RP実装の設計判断：認証器の指定・ライブラリ選定・対応ブラウザ

フローを押さえたら、残る論点は実装前に決めるべき設計判断です。ここでの選択が、対応端末の範囲・回復のしやすさ・開発工数を左右します。

authenticatorSelectionで決める認証器種別と検証要件の設計指針

登録オプションのauthenticatorSelectionは、どの認証器を、どの厳格さで受け入れるかの宣言です。主要3項目の選び方を整理します。

パスキー前提のログインを作るなら、residentKeyをrequiredにして発見可能クレデンシャルを保証し、attachmentは指定せず端末内蔵とセキュリティキーの両方を受けるのが無難です。userVerificationをrequiredにすると生体認証やPINの実施が保証され、所持と本人性を1操作で満たす耐フィッシングMFAとして扱えます。この位置づけの詳細は多要素認証（MFA）とは？3つの認証要素と実装方式・耐フィッシングMFAを実装視点で解説を参照してください。requiredはPIN未設定のセキュリティキーを弾く副作用があるため、対象ユーザーの端末事情で判断します。

SimpleWebAuthn等の実装ライブラリと自作検証を避ける判断基準

attestation・assertionの検証には、CBORのデコード、COSE形式鍵の変換、複数署名アルゴリズムの分岐が絡みます。ここを自作するとアルゴリズム混同や検証漏れの穴を作りやすいため、サーバ側は実績のあるライブラリに任せるのが安全です。TypeScriptならSimpleWebAuthn（サーバ・ブラウザ両対応のnpmパッケージ）、Javaならwebauthn4j、Pythonならpy_webauthn、Goならgo-webauthnが定番で、いずれもGitHubで仕様更新への追従が続いています。

ブラウザ対応は、Chrome・Edge・Safari・Firefoxの現行版がいずれもWebAuthn本体に対応しており、会員向けWebサービスで対応不能な環境は既に少数です。実行時はwindow.PublicKeyCredentialの存在確認を入口に、未対応環境へはパスワードログインを出し分けます。機能単位の対応差（conditional UIなど）は前述の判定APIで吸収します。

アカウント回復経路の設計とパスワード認証との並行運用の進め方

実装より難しいのが回復設計です。同期型パスキーはプラットフォームのアカウントが生きていれば端末紛失に耐えますが、プラットフォーム間の移行や同期アカウント自体の喪失には別経路が要ります。複数クレデンシャル登録の推奨導線、メール等による再登録フロー、当面のパスワード併存の3点を用意し、パスワードの即時廃止はしない段階移行が定石です。

この回復・並行運用まで含めると、パスキー対応は認証画面の改修ではなく会員基盤の設計課題になります。ログイン基盤・会員データベースの設計からパスキー対応まで含めた開発は会員管理システム開発として受託しています。既存サービスへの後付け導入も、クレデンシャル管理テーブルの設計段階からご相談ください。

WebAuthn Level 3の新機能と導入を採用する条件・見送る場面

仕様は現在も更新が続いており、Level 3で実装の選択肢が広がります。最後に、新機能の使いどころと採用判断を言い切ります。

Level 3で加わる関連オリジン対応と資格情報シグナルの使いどころ

2026年5月26日版の勧告候補（2026年7月時点）であるLevel 3には、実務に直結する追加が入っています。関連オリジンリクエスト（Related Origin Requests）は、国別ドメインなど複数オリジンで同一のrp.idを使えるようにする仕組みで、ドメインをまたぐサービス群のパスキー共通化に効きます。シグナルメソッド（signalUnknownCredentialなど）は、RP側で削除済みのクレデンシャルをパスワードマネージャーへ通知して残骸を掃除させるAPIです。getClientCapabilities()で機能単位の対応可否を一括取得できるようになり、実行時の出し分けも書きやすくなりました。

これらは勧告候補段階のため、ブラウザごとの実装状況を確認しつつ、未対応環境では従来動作に戻るプログレッシブな組み込みに留めます。認証が通った後のセッションをトークン窃取から守る動きとしては、パスキーと連携するDBSCの標準化が並行して進んでおり、DBSCの標準化動向とパスキー連携が示す認証セキュリティの未来で扱っています。

WebAuthn導入を採用する条件と見送る場面の切り分け基準

採用条件は明確です。一般消費者向けの会員サービス、フィッシングの標的になりやすいログイン、パスワードリセットのサポートコストが目に見えている事業では、WebAuthnによるパスキー対応を採用すべきです。主要ブラウザと3大プラットフォームの対応が揃った現在、技術的な障壁は回復設計に集約されており、待つ理由は薄くなっています。

逆に見送る場面も条件付きで言い切れます。IP制限された社内システムだけでフィッシング経路が事実上ない環境、利用頻度が年数回でユーザーがパスキーの存在自体を忘れる性質のサービス、回復フローの開発工数を確保できない段階での全面移行は過剰です。その場合も、まずパスワード併存のオプション提供から始めれば、リスクを増やさずに移行の足場を作れます。

よくある質問

WebAuthnの実装検討でよく挙がる疑問を、実装者の視点で簡潔にまとめます。

WebAuthnとパスキーは何が違いますか？

WebAuthnは公開鍵認証を実現するW3C標準のAPI仕様で、パスキーはそのAPIで作った発見可能クレデンシャルをiCloudキーチェーンやGoogleパスワードマネージャーが複数端末に同期する運用形態の呼び名です。実装者が書くコードはどちらもWebAuthnで、パスキー対応とは実質的にresidentKeyをrequiredにした登録と、allowCredentialsを空にした認証を指します。

WebAuthnとFIDO2の関係はどうなっていますか？

FIDO2は、W3Cが標準化したWebAuthnと、FIDOアライアンスが策定したCTAPの2仕様を合わせた総称です。WebAuthnはWebサービスとブラウザの間、CTAPはブラウザとセキュリティキー等の認証器の間を受け持ちます。RP実装で直接触るのはWebAuthnだけで、CTAPの通信はブラウザとOSが処理するため意識する必要はありません。

対応していないブラウザへの配慮は必要ですか？

Chrome・Edge・Safari・Firefoxの現行版はいずれもWebAuthn本体に対応しており、一般向けサービスで未対応が問題になる場面は減っています。実装ではwindow.PublicKeyCredentialの存在確認で出し分け、未対応環境にはパスワードログインを表示します。conditional UIなど機能単位の差は、実行時の判定APIで確認してから有効化すれば安全です。

パスワードを完全に廃止できますか？

技術的には可能ですが、即時の全面廃止は推奨しません。プラットフォーム間の移行や同期アカウント喪失に備えた回復経路が必須で、複数クレデンシャル登録の推奨、メール等による再登録フロー、当面のパスワード併存を整えたうえで段階的に減らすのが現実的です。パスワードレスへの移行は、回復設計の完成度に合わせて進めます。

サーバ側の実装には何が必要ですか？

challengeの発行と保持、登録時のattestation検証と公開鍵・credential IDの保存、認証時のassertion検証（challenge・origin・rpIdHash・flags・署名）の3点です。検証にはCBORやCOSE鍵の処理が絡むため自作せず、SimpleWebAuthn（TypeScript）、webauthn4j（Java）、py_webauthn（Python）などの実績あるライブラリを使うのが定石です。

関連記事

• パスキー認証とは？仕組み・パスワードとの違い・企業の導入判断を解説：パスキーの概念・従来認証との違い・導入判断を整理した判断ハブ。本記事の実装解説と対になるcolumn記事です。
• FIDO認証とは？仕組み・FIDO2/パスキー・導入判断までを解説：WebAuthnの土台となるFIDO規格の構成要素と認証器の機構を掘り下げています。
• 多要素認証（MFA）とは？3つの認証要素と実装方式・耐フィッシングMFAを実装視点で解説：userVerification必須のWebAuthnが耐フィッシングMFAとなる位置づけを解説しています。
• JWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いを実装視点で解説：WebAuthn認証通過後のセッション・トークン設計を受け持つ解説です。
• DBSCの標準化動向とパスキー連携が示す認証セキュリティの未来：認証後のセッション窃取対策としてパスキーと連携するDBSCの動向をまとめています。