LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

WebAuthnのサーバー側実装とは――RPが担う役割

WebAuthn/FIDO2のサーバー実装とは、公開鍵暗号方式を用いたパスワードレス認証において、Relying Party（RP、認証を要求するサービス提供者）としてchallenge発行・鍵情報の検証・保存を担う仕組みを指します^*1。ブラウザやアプリのAPIだけでは認証は完結せず、サーバー側の検証ロジックが認証の堅牢性を支えています。

WebAuthn API呼び出しとサーバー処理の対応関係

クライアント側では、登録時にnavigator.credentials.create、認証時にnavigator.credentials.getを呼び出します^*2。いずれのAPIも、呼び出し前にサーバーがchallengeを含むオプションを生成し、呼び出し後にサーバーが応答（attestationまたはassertion）を受け取って検証する構成が前提です。

MDNの解説では、RPサーバーはユーザー情報とRP情報をWebアプリに渡し、challengeとともに登録処理を開始するとされています^*2。つまりAPI呼び出し自体はブラウザ・OSが担いますが、その前後の状態管理と検証はすべてサーバー実装者の責務です。

authenticatorとRPの信頼関係

authenticator（認証器）とは、鍵ペアの生成・秘密鍵の保管・challengeへの署名を行う主体を指し、端末内蔵型（platform authenticator）と外付け型（roaming authenticator）に分かれます^*3。RPは authenticatorを直接信頼するのではなく、登録時に受け取った公開鍵と、必要に応じてattestation情報を検証することで信頼関係を構築します。

登録フロー（Registration Ceremony）――challenge発行とattestation検証

登録フローでは、RPがchallengeを生成しクライアントに渡した後、authenticatorが生成した鍵情報を検証して公開鍵を保存します。W3CのWebAuthn仕様は、この一連の手続きをRegistration Ceremonyと定義しています^*1。

challengeはRPが生成する乱数である

仕様では、challengeはサーバー側で生成される値であり、MDNの解説でも「challengeは少なくとも16バイトのランダムな情報のバッファでなければならない」とされています^*2。予測可能な値や再利用された値を使うと、リプレイ攻撃（過去の応答を再送する攻撃）を許してしまいます。

実装では、challengeを都度サーバー側のセッションやキャッシュにnonce（一度限り使用する値）として保存し、クライアントからの応答に含まれるchallengeと突き合わせたうえで破棄する設計が必要です。有効期限を設けず使い回すと、検証の意味が失われる点に注意が必要です。

attestationで認証器の来歴を確認する

attestation（証明）とは、authenticatorが自身の来歴や真正性についてRPに提示する任意の証跡です^*4。W3C仕様は、attestationを「authenticatorの出自と、それが発行するデータの出自について検証可能な証拠を提供するために用いる」ものと位置づけています^*1。

MDNによれば、登録時のRP側検証には「challengeが送信したものと一致するか」「オリジンが期待通りか」「署名とattestationが認証器の機種に対応した正しい証明書チェーンを使っているか」の確認が含まれます^*2。すべての利用シーンでattestationの厳密な検証が必須というわけではなく、要求レベル（none／indirect／direct等）はRPの方針として設計時に決定します。

公開鍵と認証情報の保存設計

検証を通過した後、RPは公開鍵・credential ID・signCount（署名カウンタ）の初期値をユーザーアカウントに紐づけて保存します。1ユーザーが複数のauthenticator（PCとスマートフォン等）を登録できるよう、credential単位で複数レコードを持てるデータ設計が実務上望まれます。

認証フロー（Authentication Ceremony）――assertion検証と署名カウンタ

認証フローでは、登録済みの公開鍵を用いてassertion（クライアントが返す署名付き応答）を検証し、ログインの可否を判定します。この一連の手続きをAuthentication Ceremonyと呼びます^*1。

assertion検証で確認する3つの項目

MDNの解説では、認証時の検証項目として「登録時に保存した公開鍵で署名を検証すること」「authenticatorが署名したchallengeが、サーバーが生成したchallengeと一致すること」「Relying Party IDがこのサービスで期待される値であること」の3点が挙げられています^*2。いずれか1つでも欠けると、不正なログイン試行を排除できません。

サーバーはcredential IDを手がかりに保存済みの公開鍵をデータベースから引き当て、署名検証を行います^*1。credential IDが未登録の値であれば、その時点で認証を拒否します。

署名カウンタ（signCount）でクローン検知する

署名カウンタとは、authenticator dataに含まれる値で、authenticatorが認証を行うたびに増加する計数器です^*1。RPは認証のたびに受け取ったsignCountを保存済みの値と比較し、増加していることを確認します。

もし受け取ったsignCountが保存済みの値以下であれば、認証器が複製されている可能性を疑う根拠になります。ただし、一部のauthenticatorは仕様上signCountを常に0で返す実装（同期パスキーに多い）があるため、0が続く場合はカウンタ比較を無条件の拒否条件にしない設計が必要です。

User Verification（UV）とUser Presence（UP）の区別

User Verification（UV）とは、生体認証・PIN・デバイスパスワードなどによる本人確認を要求する検証レベルです^*5。一方、User Presence（UP）は、認証器が利用者の物理的な近接を確認する簡易的なテストにとどまります^*5。

RPは認証要求時にuserVerificationパラメータで”required”「preferred」「discouraged」のいずれかを指定し、authenticator dataのUVフラグを検証します。金融取引や機密情報へのアクセスではUV必須、社内ツールへの軽量ログインではUP相当でも許容するなど、リスクに応じた使い分けが求められます。

RP IDとオリジン検証――なりすましを防ぐ設計の勘所

RP ID（Relying Party Identifier）とは、authenticatorが発行する鍵の適用範囲（スコープ）を決定する識別子であり、通常はサービスのドメイン名を指定します^*1。RP IDの設計を誤ると、意図しないサブドメインへの鍵の適用範囲拡大や、逆に必要な範囲を認証器がカバーできない不整合が生じます。

RP IDはオリジンのドメイン部分と一致させる

RP IDには、サービスのオリジン（スキーム・ホスト・ポートの組）のうち、ホスト部分と一致するか、その親ドメインを指定する必要があります。MDNのサンプルコードでも、認証時のオプションにrpId: "acme.com"のようにドメインを明示する例が示されています^*2。

フィッシングサイトが正規サービスと異なるドメインで運用される限り、RP IDの不一致によって認証器が署名を拒否します。これがWebAuthnのフィッシング耐性の技術的な根拠です^*3。

オリジン検証を省略しない

クライアントデータ（clientDataJSON）には、実際にAPIを呼び出したオリジンの情報が含まれます。RPはこの値が期待するオリジンと一致するかを検証します^*2。オリジン検証を省略すると、正規のRP IDを騙った別オリジンからのリクエストを通してしまう可能性があります。

マルチテナント構成やサブドメイン運用（例：複数の顧客企業ごとに異なるサブドメインを割り当てる場合）では、RP IDの共有範囲を事前に設計し、意図しないテナント間での認証情報の越境を防ぐ必要があります。

パスキーとの関係――discoverable credentialと同期の扱い

パスキーとは、WebAuthn/FIDO2の資格情報のうち、ユーザーIDを事前に提示しなくてもRPへのログインに利用できるdiscoverable credential（resident keyとも呼ばれる）を指します^*6。サーバー実装の観点では、discoverable credentialに対応するかどうかで登録・認証両フローの設計が変わります。

discoverable credentialとusernameless認証

discoverable credentialに対応する場合、認証時にRPはcredential IDのリスト（allowCredentials）を事前に提示せず、authenticator側にユーザー識別情報を保持させる設計が可能になります。これによりusernameless（ID入力を省略した）ログイン体験を実現できますが、RP側は認証応答からユーザーを一意に特定するロジック（userHandleの活用等）を実装する必要があります。

同期パスキーとデバイス紐付き認証情報の違い

パスキーには、クラウド経由で複数端末に同期される同期パスキーと、特定の端末のセキュアハードウェアに固定されるデバイス紐付き認証情報の2種類があります。RP側からは、attestationの種類やAAGUID（authenticatorの型式を示す識別子）を手がかりに、どちらの性質の認証情報が登録されたかを判別できる場合があります。

ただし、同期パスキーは複数の端末で同一の秘密鍵相当の情報が共有されるため、signCountが常に0で返る実装が一般的です。RPの検証ロジックでは、この挙動を異常とみなさない設計にしておく必要があります。

既存ID基盤からの移行とフォールバック設計

パスワード認証からWebAuthnへの移行では、既存の認証基盤（IDプロバイダー・セッション管理・多要素認証機構）との接続点を整理し、段階的な移行計画を立てる必要があります。全ユーザーを一斉に切り替える設計は、対応端末を持たない利用者を締め出すリスクを伴います。

既存IDとの紐付け設計

移行の第一段階では、既存アカウントに対してWebAuthn認証情報を追加登録できる導線を用意します。ログイン中のユーザーに対して登録フローを提示し、公開鍵をアカウントに追加する形が一般的です。パスワードを即座に廃止せず、当面はパスワードとWebAuthnの両方でログインできる併用期間を設けることで、移行に伴う問い合わせ増加を抑えられます。

フォールバック手段の設計

authenticatorを紛失した場合や、対応端末を持たない利用者への対応として、SMS・メールによるワンタイムコードなど代替の認証手段を維持する設計が必要です。フォールバック手段自体がフィッシング耐性を持たない場合、WebAuthn導入によるセキュリティ向上効果を弱める可能性があるため、フォールバックの利用条件（利用回数制限・追加確認の要求等）をあわせて設計します。

IPA（情報処理推進機構）は、パスワードに代わる新たなログイン認証手段としてパスキーの利用を呼びかけており、生体認証やデバイスのロック解除機能を使った認証方式として紹介しています^*7。国内の公的機関でもパスワードレス化の方向性が示されている状況を踏まえ、移行計画は中長期的な視点で立てる必要があります。

複数authenticatorの管理画面を用意する

ユーザーが複数の端末で異なるauthenticatorを登録できるようにし、管理画面から登録済み認証情報の一覧確認・削除ができる機能を用意します。端末紛失時に該当のcredentialだけを無効化できる設計にしておくことで、アカウント全体を停止せずに済むリカバリ対応が可能になります。

外注か内製か――サーバー実装の委託判断軸

WebAuthnのサーバー実装は、暗号処理・仕様準拠・既存システムとの統合という複数の専門領域にまたがります。内製で完結させる場合、暗号技術・認証プロトコル・既存ID基盤の3領域を理解したエンジニアの確保が前提になります。

内製が難しくなりやすいポイント

attestationの検証や証明書チェーンの確認は、仕様変更への追随が必要な領域です。自前で全処理を実装すると、W3C仕様の改訂（Level 2からLevel 3への移行等）のたびに検証ロジックの見直しが発生します。OSSのWebAuthnサーバーライブラリ（言語ごとに複数存在)を活用する場合も、ライブラリの検証範囲がどこまでかを把握したうえで、自社の既存ID基盤との接続部分は独自に実装する必要があります。

既存のOAuth2/OIDC基盤にWebAuthnを組み込む場合、認証成功後のトークン発行フローとの整合性を取る設計が求められます。ここは既存システムの構造に依存する部分が大きく、外部知見を要する場面です。

外注が効果的な場面

サーバー実装の外注が有効なのは、既存ID基盤とWebAuthnの接続設計、attestation検証ポリシーの策定、複数authenticatorの管理機能の設計といった、仕様理解とシステム設計の両方が必要な工程です。実装後のセキュリティレビュー（challenge管理・RP ID設計・signCount運用の妥当性確認）も、第三者の視点を入れる価値があります。

委託先を選定する際は、WebAuthn仕様への準拠実績、既存認証基盤との統合経験、そして仕様変更への追随体制を確認することが有益です。LASSICは元請（プライムベンダー）としてシステム保守・運用を受託しており、認証基盤の受託開発における要件整理から既存システムとの統合まで一気通貫で対応しています。

まとめ：WebAuthnサーバー実装で押さえる3つの判断軸

本稿では、WebAuthn/FIDO2によるパスワードレス認証のサーバー（RP）側実装について、登録・認証フローの検証項目からパスキーとの関係、移行設計までを整理しました。要点を3つに集約します。

第一に、RPの実装はchallenge発行・attestation/assertion検証・公開鍵とsignCountの管理という一連の処理を、仕様に忠実に実装することが前提になります。RP IDとオリジンの検証を省略すると、フィッシング耐性という中核の利点が損なわれます。

第二に、discoverable credentialへの対応や同期パスキーの扱いは、RPの検証ロジック設計に直接影響します。signCountが常に0で返る実装があることも踏まえ、異常検知のロジックを柔軟に設計する必要があります。

第三に、既存のパスワード認証基盤からの移行は、併用期間とフォールバック手段の設計が実務上の分かれ目になります。内製で仕様変更への追随まで維持するには専門知見の継続的な確保が必要であり、外部パートナーの活用も選択肢になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：W3C「Web Authentication: An API for accessing Public Key Credentials – Level 3」
2. *2　出典：MDN Web Docs「Web Authentication API」
3. *3　出典：Apple Developer Documentation「Supporting Passkeys」（2024年）
4. *4　出典：FIDO Alliance「Passkeys」
5. *5　出典：passkeys.dev「Glossary of Terms」
6. *6　出典：passkeys.dev「Glossary of Terms（Discoverable Credential）」
7. *7　出典：IPA（独立行政法人情報処理推進機構）「インターネットサービスへの不正ログインによる被害が増加中」（2025年8月）

Tweet