パスキーはなぜ安全なのか ── 仕組み・同期・紛失時の注意点を図解

「指紋でログインできるから安全」。パスキーはこう紹介されることがありますが、安全性の中心は指紋や顔そのものではありません。ログイン先へ秘密鍵を渡さず、そのサイト用の鍵を持っていることを署名で証明する点にあります。¹

ただし、「パスキーなら絶対に乗っ取られない」「秘密鍵は必ずスマホから出ない」と理解すると、同期や紛失時の判断を間違えます。ログインの仕組みが強くなることと、端末・回復手段・ログイン後のセッションまで自動的に安全になることは、別の話です。

この記事では、パスワードとの違いから登録・ログインの流れを図解し、フィッシングに強い理由、同期型とデバイス固定型の違い、端末を失くしたときの対応を順に整理します。後半では、自社WebサービスやWindowsの業務システムへ導入する際の確認点を扱います。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全38件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

1. パスキーが安全な理由は3つある

パスキーは、パスワードの代わりにログインに使える公開鍵暗号ベースの資格情報です。登録時に作った鍵ペアのうち、秘密鍵は利用者側で管理し、公開鍵をサービス側へ登録します。Webでの登録・認証にはWebAuthnという標準APIを使います。¹²

flowchart TB
        accTitle: パスキーが変える3つの認証上の弱点
        accDescr: 秘密の受け渡し、応答の再利用、使用先の取り違えに、それぞれ別の仕組みで対処します。
        A["パスキーによるログイン"] --> B["秘密鍵を渡さず署名を返す"]
        A --> C["チャレンジを照合して消費する"]
        A --> D["RP IDとオリジンを確認する"]
        B --> E["公開鍵だけでは署名を偽造できない"]
        C --> F["過去の応答を再利用させない"]
        D --> G["無関係な偽サイトでは使わせない"]

図1: パスキーの強さは、暗号・使い捨ての要求・使用先の制限を組み合わせることにあります。

この記事でいう「秘密鍵を送らない」の送り先は、ログインするサービスのサーバーです。同期型パスキーでは、秘密鍵を暗号化して保管・複製する別の経路があります。ここを分けると、「クラウドに同期するのに、秘密を送らないとはどういうことか」という疑問が解けます。

また、サーバーは公開鍵以外にも、資格情報の識別子、アカウントとの対応、セッション情報などを持ちます。「公開鍵だけではなりすませない」と「データベースを守らなくてよい」は同じ意味ではありません。²

2. 長いパスワードやワンタイムコードでは何が残るのか

通常のパスワード認証では、利用者が入力したパスワードをTLSで保護された通信でサーバーへ送り、サーバーが保存済みのハッシュなどと照合します。適切なソルト付きハッシュと十分な計算コストは、保存データの流出後に推測を繰り返す攻撃を難しくします。ランダムで長く、使い回さないパスワードにも意味があります。³

同じパスワードを複数サービスで使い回すと、1か所から漏れたIDとパスワードの組を別サイトへ試す「パスワードリスト攻撃」によって、他のアカウントにも被害が広がるおそれがあります。長いパスワードでも、使い回していればこの波及を防げません。⁴

それでも、正しいパスワードを間違った相手に渡せてしまう点は残ります。攻撃者が用意したサイトに本物のパスワードを入力すると、そのサイトのTLS証明書が正しくても、入力値は攻撃者へ届きます。TLSが破られたのではなく、安全に通信している相手を取り違えているのです。

sequenceDiagram
        accTitle: 偽サイトへの入力はTLSだけでは防げない
        accDescr: 利用者が偽サイトに入力したパスワードとコードは、暗号化通信であっても偽サイトの運営者へ届きます。
        participant U as 利用者
        participant P as 偽サイト
        participant S as 本物のサービス
        U->>P: 本物のパスワードを入力
        P->>S: 入力されたパスワードを中継
        S-->>P: 追加認証を要求
        P-->>U: ワンタイムコードを要求
        U->>P: コードを入力
        P->>S: 有効なうちにコードを中継
        S-->>P: 検証に成功するとセッションを発行

図2: パスワードとコードをリアルタイムに中継するAiTM型フィッシングの概略です。

TOTPは認証アプリとサーバーが共通のシードを持ち、時刻に応じたコードを生成する方式です。ログインのたびにシードそのものを送るわけではありません。ただし、利用者が入力するコードは正規サイトのドメインに結び付いていないため、有効期間内に偽サイトから中継される余地があります。SMSコードにも、偽サイトへ入力できるという問題があります。³

これは多要素認証が無意味だという話ではありません。パスワードだけの認証より防げる攻撃は増えます。そのうえで、コードの手入力まで狙う攻撃に対しては、FIDO/WebAuthnのようなフィッシング耐性のある認証へ進む意味があります。⁵

パスワードマネージャーで強いパスワードを生成し、正しいドメインだけに自動入力する対策も有効です。しかし、そのパスワードをコピーして別の入力欄へ渡すことはできます。パスキーは、利用者の操作だけでこの使用先の制約を外せない点が異なります。

3. 登録とログインでは何が行き来するのか

登録では、鍵ペアを作ってアカウントに結び付ける

パスキーを扱う役割は、大きく3つです。サービス側のRP（Relying Party）、WebAuthnを提供するブラウザーやOS、そして鍵の生成・利用を担う認証器です。認証器には、OSの機能や資格情報マネージャーと連携するもの、外付けのFIDO2セキュリティキーなどがあります。顔や指紋の照合は、その利用を許可するための処理です。²⁶

sequenceDiagram
        accTitle: パスキー登録の流れ
        accDescr: 登録要求に応じて鍵ペアを作り、サービスが登録応答を検証して公開鍵と資格情報IDをアカウントへ結び付けます。
        participant S as サービス
        participant B as ブラウザーとOS
        participant A as 認証器
        S->>B: チャレンジとアカウント情報
        B->>B: 使用先を確認
        B->>A: 資格情報の作成要求
        A->>A: 本人確認と鍵ペア生成
        A-->>B: 公開鍵と資格情報IDなど
        B->>S: 登録応答を送信
        S->>S: 登録応答を検証
        S->>S: アカウントへ資格情報を登録

図3: 登録するのは公開鍵だけではなく、識別子や検証用データを含む応答です。秘密鍵はログイン先へ送りません。

credential ID（資格情報ID）は、どのパスキーかを識別するための値です。サーバーはこれを公開鍵やアカウントに対応付けて保存します。新しいパスキーを既存アカウントへ追加するときは、まず既存の方法でそのアカウントの利用者であることを確認し、必要に応じて再認証します。ブラウザーから送られたユーザー名だけで登録先を決めてはいけません。⁶⁷

通常、別のサービスや別アカウントに登録する際には別の鍵ペアを作るため、パスワードの使い回しに相当する運用を利用者がする必要はありません。ただし、メールアドレスなど別の情報による利用者の照合まで防ぐ仕組みではなく、「パスキーを使えば匿名になる」という意味ではありません。

ログインでは、今回の要求に対する署名を返す

ログイン時には、サーバーが予測困難な乱数であるチャレンジを発行します。認証器は秘密鍵で署名を作り、ブラウザーがそれをサーバーへ返します。サーバーは登録済みの公開鍵で検証し、今回発行した要求への正しい応答かを確かめます。⁶

sequenceDiagram
        accTitle: パスキーログインの流れ
        accDescr: 認証器が今回の要求に結び付く署名を作り、サーバーが署名とチャレンジ、使用先、アカウントを検証します。
        participant S as サービス
        participant B as ブラウザーとOS
        participant A as 認証器
        S->>B: 未使用のチャレンジとRP ID
        B->>B: 使用先の妥当性を確認
        B->>A: RP IDとデータのハッシュ
        A->>A: 生体認証やPINで確認
        A->>A: 秘密鍵で署名
        A-->>B: 認証器データと署名
        B->>S: 資格情報IDと認証応答
        S->>S: 応答とアカウントを検証
        S-->>B: 成功時だけセッション発行

図4: ログインの応答は「秘密鍵を持っていることの証明」であり、秘密鍵そのものではありません。

より正確には、認証時の署名対象は次のデータです。|| はバイト列の連結を表します。⁸

署名対象 = authenticatorData || SHA-256(clientDataJSON)

clientDataJSON:
  type       認証なら webauthn.get
  challenge  サーバーが発行したチャレンジ
  origin     呼び出し元のオリジン

authenticatorData:
  rpIdHash   RP IDのSHA-256ハッシュ
  flags      利用者の在席やユーザー検証などの結果
  signCount  署名カウンター

「チャレンジに署名する」は全体をつかむための略した説明です。実際には使用先や認証器の状態も署名の検証に関係します。認証器がWebページを読んでオリジンを判定するのではなく、ブラウザーが集めたクライアントデータのハッシュを受け取る、という役割分担も重要です。

flowchart TB
        accTitle: 認証時に署名へ結び付けるデータ
        accDescr: チャレンジとオリジンを含むクライアントデータのハッシュを、RP IDのハッシュなどを含む認証器データと連結して署名します。
        A["チャレンジとオリジンなど"] --> B["clientDataJSONのハッシュ"]
        C["RP IDのハッシュとフラグなど"] --> D["authenticatorData"]
        B --> E["認証器データとハッシュを連結"]
        D --> E
        E --> F["秘密鍵で署名"]

図5: チャレンジだけでなく、使用先や認証器の状態も署名の検証に関わります。

過去の署名が再利用できないのは、署名自体が時間で消えるからではありません。サーバーがチャレンジをログイン試行に結び付け、期限を設け、一度使った要求を再度受け付けないからです。公開鍵による署名検証に成功することだけでは、ログインを許可する条件として足りません。

4. なぜ本物そっくりの偽サイトでも使えないのか

RP IDとオリジンは役割が違う

RP IDは資格情報のスコープを決めるドメイン名で、通常は example.com のように指定します。一方、オリジンはスキーム・ホスト・ポートの組です。たとえば https://login.example.com がオリジン、example.com がRP IDという構成が考えられます。⁹

通常のドメイン関係による検証では、login.example.com のページからRP IDに example.com を指定できます。しかし、無関係な examp1e.com のページから example.com を指定して、本物用のパスキーを使うことはできません。見た目が似ているかどうかではなく、ブラウザーが使用先の関係を検証します。

flowchart TB
        accTitle: RP IDによる資格情報の使用先の制限
        accDescr: 正規のドメイン関係を持つページと無関係な偽サイトでは、本物のRP IDを要求した際のブラウザーの判断が異なります。
        A["RP IDにexample.comを指定"] --> B{"呼び出し元はどこか"}
        B -->|"login.example.com"| C["ドメイン関係の条件を満たす"]
        B -->|"examp1e.com"| D["無関係なドメインなので拒否"]
        C --> E["対応するパスキーで認証を進める"]
        E --> F["サーバーでも許可したオリジンか検証"]
        D --> G["本物用のパスキーは使えない"]

図6: ブラウザーの使用先制限とサーバーのオリジン検証の両方が、フィッシング耐性を支えます。

サーバー側でも、署名と一緒に返された origin が許可済みのオリジンか、rpIdHash が期待するRP IDのハッシュかを検証します。偽サイト自身のRP IDで作った鍵や、許可していないオリジンの応答を、本物のアカウントの認証として受け入れてはいけません。⁸

なお、WebAuthn Level 3には、サービス側が明示的に関連付けた別オリジンで同じRP IDを使うためのRelated Origin Requestsもあります。「ホスト名が完全一致しなければ常に使えない」という説明も正確ではありません。重要なのは、サービスが認めた範囲に資格情報の利用を閉じることです。関連オリジンを使う場合も、サーバーの許可リストを無制限に広げる話ではありません。⁹

「フィッシング耐性」は、あらゆる詐欺への耐性ではない

ここまでの説明は、ブラウザー・OS・認証器が信頼でき、サーバーが必要な検証を行う前提です。正規サイトの侵害や端末上のマルウェア、弱いアカウント回復手順まで、WebAuthnだけで解決できるわけではありません。

偽サイトに「パスキーが使えないので、パスワードとSMSコードを入力してください」と誘導され、別のログイン経路を使ってしまうこともあり得ます。パスキーは本物の資格情報を偽サイトへ渡す事故に強いのであって、利用者が今後一切注意しなくてよいという意味ではありません。⁵

5. 指紋・顔・PINは、サーバーへのパスワードではない

パスキーの利用で指紋や顔を求められるのは、秘密鍵を使う操作を、その端末の正当な利用者が承認しているか確認するためです。この処理をユーザー検証（User Verification、UV）と呼びます。WebAuthnの認証応答に、指紋画像や顔の特徴量を載せてログイン先へ送ることはありません。¹²

flowchart TB
        accTitle: 端末での本人確認とサービスでの署名検証
        accDescr: 指紋、顔、PINは利用者側で鍵の使用を許可するために使い、サービス側は生体情報ではなく署名と検証結果を確認します。
        A["指紋・顔・PINで確認"] --> B["認証器が秘密鍵の使用を許可"]
        B --> C["署名付きの認証応答を作成"]
        C --> D["サービスが公開鍵で検証"]
        D --> E["要求したユーザー検証の結果も確認"]

図7: 端末のロック解除とサービスへの認証は連携しますが、サーバーが指紋やPINを照合するわけではありません。

PINで使えるならパスワードと同じでは、と感じるかもしれません。違いは、そのPINを何と照合するかです。ここでのPINは認証器の利用を許可するためのもので、Webサイトが全利用者分を持ち、ログインのたびに受け取るパスワードではありません。適切な認証器では、誤入力の回数制限なども働きます。³

ただし、端末を盗まれ、そのロック解除方法まで知られていれば、攻撃者がパスキーを使える危険は高まります。顔認証に切り替えたから端末のパスコードは簡単でよい、とはなりません。また、画面へのタッチなどを示すユーザー在席（User Presence、UP）と、生体認証やPINによるUVは別のフラグです。実装側は、必要なUVを要求し、応答でも確認します。

6. 同期型とデバイス固定型では、守る場所が違う

パスキーには、端末間で同期されるものと、特定の認証器に結び付くものがあります。両者ともログイン先へ秘密鍵を渡さずに認証しますが、鍵の保管・複製・復旧の方法が異なります。¹⁰

flowchart TB
        accTitle: 同期とログインは別の経路
        accDescr: 同期型は暗号化した保管庫を通じて鍵を複製しますが、ログイン先に送るのは同期型も固定型も認証応答です。
        V["暗号化された同期保管庫"] <-->|"同期・復旧"| A["端末Aの同期型パスキー"]
        V <-->|"同期・復旧"| B["端末Bの同じパスキー"]
        A -->|"署名付き応答"| S["ログイン先のサービス"]
        B -->|"署名付き応答"| S
        K["固定型の認証器"] -->|"署名付き応答"| S

図8: 秘密鍵を複製する同期経路と、サービスへのログイン経路を分けると、両者の違いを理解できます。

AppleやGoogleの仕組みでは、同期するパスキーをエンドツーエンド暗号化で保護します。サービス提供者が、クラウド上の保存データをそのまま読んで秘密鍵を取得できるという設計ではありません。¹¹¹²

一方、新しい端末で復旧するには、同期アカウントへのサインインに加えて、以前の端末の画面ロックや保管庫のPINなどが必要になる場合があります。具体的な条件は製品・設定によって異なります。「クラウドアカウントのパスワードだけで全パスキーを復元できる」とも、「クラウドアカウントさえ戻れば必ず復元できる」とも言えません。¹¹¹³

同期型では、保管庫の解除・回復手段や参加端末まで含めて侵害されると、複数サービスへの影響が広がるおそれがあります。同期アカウントの多要素認証、強い端末ロック、回復先の管理が重要です。サービスが対応する場合は物理セキュリティキーによる保護も検討します。ただし回復用の鍵まで同じ端末や同じ保管庫だけに置くと、まとめて失う構成になります。

組織の保証レベルにも注意が必要です。NIST SP 800-63B-4では、同期可能な認証器は条件を満たせばAAL2で使えますが、秘密鍵のエクスポートを認めないAAL3には使えません。逆に、デバイス固定型なら自動的にAAL3になるわけでもなく、ハードウェア保護など残りの要件を満たす必要があります。¹⁴¹⁵

QRコードでスマホを使う方法は、同期とは違う

PCに表示されたQRコードをスマホで読み取り、そのスマホのパスキーでログインする方法もあります。FIDOのクロスデバイス認証ではBluetoothなどで近接を確認し、スマホ側で認証を行います。これはスマホの秘密鍵をPCへコピーする操作ではありません。¹⁶¹

flowchart TB
        accTitle: スマホの鍵で別のPCへログインする流れ
        accDescr: PCのQRコードをスマホで読み取り、近接確認とスマホでのユーザー検証を経て認証します。秘密鍵をPCへコピーする流れではありません。
        A["PCのログイン画面でQRを表示"] --> B["スマホでQRを読み取る"]
        B --> C["端末どうしの近接を確認"]
        C --> D["スマホでユーザー検証と署名"]
        D --> E["サービスが認証応答を検証"]
        E --> F["PCでログインが成立"]

図9: クロスデバイス認証は、手元のスマホを認証器として使い、PCには鍵を複製しません。

同期先が同じでないPCからでも使える場合がありますが、鍵を保存したスマホを失くした際の予備にはなりません。「PCからログインできた」と「PCにも独立したパスキーが登録されている」は区別してください。

7. スマホを失くしたときは、端末・資格情報・セッションを分けて止める

紛失時は、安全な端末から遠隔ロックなどを手配し、悪用が疑われる場合はサービスや組織の窓口へ速やかに連絡します。並行して、予備のパスキーや回復手段でアカウントへ入れるか確認します。復旧が終わるまで紛失の届け出や利用停止を待つ必要はありません。端末の保護、同期アカウントの保護、サービス側の失効は役割が異なります。¹⁷¹⁸

flowchart TB
        accTitle: 端末紛失時に分けて確認すること
        accDescr: 紛失端末の保護と窓口への連絡を進めながら、安全な回復手段を確認します。パスキーの失効と既存セッションの終了は別々に行います。
        A["端末を紛失した"] --> B["遠隔ロックなどと窓口への連絡"]
        A --> C["予備の鍵や回復手段を確認"]
        B --> D["危険なパスキーの利用を停止"]
        C --> E["安全な端末で管理画面へ入る"]
        D --> F["既存セッションも別途終了"]
        E --> F
        F --> G["同期先と登録済み認証方法を確認"]
        G --> H["安全な環境で新しい鍵と予備を用意"]

図10: 端末を止める処理、パスキーを失効させる処理、ログイン済み状態を終了する処理は別です。

固定型なら、サービス側で失くした認証器の資格情報を失効させ、別途登録した予備の資格情報を使う、という切り分けができます。同期型では、複数端末のコピーがサービスから見て同じ資格情報であるため、その資格情報をサービス側で削除すると、他の端末のコピーも同じサービスへログインできなくなります。端末1台のコピーだけを、サービス側から個別失効できるとは限りません。¹⁰²

遠隔消去も、端末がオフラインなら直ちに反映されるとは限りません。Appleの「探す」では、オフライン端末の消去は次にオンラインになったときに始まります。¹⁹同期アカウントから端末を外したことだけで、その端末にある秘密鍵のコピーまで確実に使えなくなったと判断するのは危険です。悪用の懸念がある場合は、各サービス側で対象の資格情報を速やかに停止・失効させる判断が必要です。ログインできない場合は公式の窓口を利用し、正規の利用者が戻るための手続きも並行して確認します。

また、パスキーを削除しても、それだけで既存セッションがすべて終了するとは限りません。サービスの「すべての端末からログアウト」などの機能を別途確認し、不審なパスキーや回復先が追加されていないかも確認します。²⁰¹⁸

紛失する前には、重要なサービスが複数パスキーの登録に対応するか調べ、独立した予備を登録して実際にログインできるか試しておくと安心です。同期で同じ鍵が2台にあることは便利ですが、別の鍵をもう1本登録したこととは異なります。最後のログイン手段を削除する前には、回復コードの保管先も含めて、戻れる手段を確認してください。

8. パスキーでも残る弱点はどこか

パスキーは認証の重要な部分を強くしますが、アカウントへ入る経路は通常のログイン画面だけではありません。導入時は、「パスキーを使う人が増えたか」に加えて、次の経路を点検します。

flowchart TB
        accTitle: パスキー導入後にも残る攻撃経路
        accDescr: パスキーログインとは別に、弱い代替手段、回復手続き、端末や保管庫、既存セッションが攻撃対象として残ります。
        B["弱い代替ログイン"] --> A["アカウントへの不正アクセス"]
        C["回復手続きの悪用"] --> A
        D["端末・保管庫の侵害"] --> A
        E["セッションの悪用"] --> A

図11: 通常のパスキーログインが強くても、別の入口やログイン後の状態は個別に守る必要があります。

代替ログイン。 パスワードやSMSだけで同じ操作ができるなら、攻撃者はそちらを狙えます。とはいえ、予備や復旧の確認前に一斉に無効化すると正規の利用者も締め出します。対応端末、予備の鍵、サポート手順を整え、対象を絞って段階的に縮小します。⁵

アカウント回復と鍵の追加。 「端末が壊れた」という申告だけで本人確認を緩めると、攻撃者自身のパスキーを登録させる経路になります。重要なアカウントでは回復申請の確認、認証方法の追加・削除時の再認証、変更通知、監査を組み合わせます。通知を出すだけで未承認の登録を防げるわけではないため、登録前の確認が必要です。¹⁸

端末と同期保管庫。 OSやブラウザーの更新、端末ロック、保管庫の参加端末の把握は引き続き必要です。パスキーは安全でないPCを安全なPCへ変える機能ではありません。共有端末では、誰が資格情報を使用できる構成なのかも確認します。

セッション。 一般的なセッションクッキーが盗まれて使える状態なら、攻撃者は新たなパスキー認証をせずに操作できることがあります。Secure、HttpOnly、適切なSameSite、有効期間、再認証、サーバー側の失効などを別途設計します。HttpOnlyはJavaScriptによるクッキーの読み取りを制限しますが、XSSによるログイン済み操作の悪用まで防ぐものではありません。²⁰

9. 自社Webサービスへ導入するときの要点

APIを呼ぶだけで、ログインの実装が完成するわけではない

WebAuthnの登録APIは navigator.credentials.create()、認証APIは navigator.credentials.get() です。FIDO2はWebAuthnとCTAPからなり、CTAPは外付けセキュリティキーなどの認証器とクライアントがやり取りするための仕様です。Webサービスの実装者が、USBやBluetoothの通信まで自作する必要はありません。²¹

flowchart TB
        accTitle: Webサービスへのパスキー実装の分担
        accDescr: サーバーが要求の発行と検証を担い、ブラウザーがAPIを提供し、認証器が鍵を使う構成です。
        S["サーバー：要求発行と応答検証"] <-->|"要求と応答"| B["ブラウザー：WebAuthn API"]
        B <--> O["OSや資格情報マネージャーとの連携"]
        B <-->|"CTAPなど"| A["外付け認証器"]

図12: ブラウザーでの呼び出しと、サーバーでの検証・アカウント管理をセットで実装します。

次はAPIに渡す値の位置を示すブラウザー側の骨格です。この断片だけでは登録・ログインは完了しません。registrationOptionsとauthenticationOptionsはサーバーが今回の試行用に作った値であり、challenge、user.id、資格情報IDなどのバイナリ項目は、JSONのBase64URL文字列のままではなく、適切なバイト列へ変換済みとします。²

// 登録ボタンの操作から呼ぶ。オプションはサーバーで発行・保存する。
async function createPasskey(registrationOptions) {
  if (!window.isSecureContext || !window.PublicKeyCredential) {
    throw new Error("この環境ではパスキーを利用できません。");
  }
  const credential = await navigator.credentials.create({
    publicKey: registrationOptions,
  });
  if (!credential) throw new Error("パスキーの登録が完了しませんでした。");
  return credential;
  // 呼び出し側で登録応答をシリアライズしてサーバーへ送る。
  // サーバーの検証が成功するまで、登録完了とは表示しない。
}

// ログインボタンの操作から呼ぶ、通常の認証フロー。
async function usePasskey(authenticationOptions) {
  if (!window.isSecureContext || !window.PublicKeyCredential) {
    throw new Error("この環境ではパスキーを利用できません。");
  }
  const assertion = await navigator.credentials.get({
    publicKey: authenticationOptions,
  });
  if (!assertion) throw new Error("パスキーの認証が完了しませんでした。");
  return assertion;
  // 呼び出し側で認証応答をシリアライズしてサーバーへ送る。
  // サーバーが検証し、成功した場合だけセッションを作る。
}

実際の画面では、拒否されたPromiseを呼び出し側で処理し、キャンセル・タイムアウト・未対応環境などを案内します。登録応答のバイナリ変換や通信には、採用するライブラリの対応APIを使うと実装漏れを減らせます。

登録オプションの authenticatorSelection.residentKey: "required" は、アカウントを選んで使えるディスカバラブル資格情報を要求する設定です。生体認証やPINによる確認を必須にする設計では 登録では authenticatorSelection.userVerification: "required"、認証では userVerification: "required" を指定します。user.id はサーバーが発行する最大64バイトの不透明な識別子とし、メールアドレスそのものを使わず、表示名とは区別します。⁷

ログイン欄の自動入力候補として提示するConditional UIを使う場合は、PublicKeyCredential.isConditionalMediationAvailable()で対応を確認し、mediation: "conditional"と入力欄のautocomplete="username webauthn"を組み合わせます。非対応環境向けには、上のようなボタンからの通常フローを残します。²²

サーバーが検証する項目を、先に設計する

暗号部分の検証には、Node.jsならSimpleWebAuthn、.NETならfido2-net-libなどのライブラリを利用できます。ただし、ライブラリがあればアカウントとの紐付けや回復設計まで自動で安全になるわけではありません。²³²⁴

この表は実装の確認観点であり、仕様にある検証手順の代わりではありません。iframeや関連オリジンなどを利用する場合は、その追加条件も含めて確認します。通常の明示的な認証ではUPを確認し、UVを必須としたなら応答のUVも確認します。⁷⁸

flowchart TB
        accTitle: サーバー側の認証判定
        accDescr: 今回の要求との対応、使用先、資格情報の所有者、署名とポリシーをすべて確認してからセッションを発行します。
        A["認証応答を受信"] --> B{"今回の未使用要求と一致するか"}
        B -->|"はい"| C{"使用先と所有アカウントが正しいか"}
        C -->|"はい"| D{"署名と必要な検証結果が正しいか"}
        D -->|"はい"| E["要求を一度だけ消費してセッション発行"]
        B -->|"いいえ"| X["認証を拒否"]
        C -->|"いいえ"| X
        D -->|"いいえ"| X

図13: 正しい署名であることと、今回そのアカウントへログインさせてよいことを、両方確認します。

signCountも万能なクローン検出器ではありません。カウンターを持たず0を返す認証器があり、値が単調増加しない理由にも複製以外の可能性があります。同期型を含む採用環境とライブラリの扱いを確認し、異常値をリスク判断に利用します。「前回以下なら必ずクローン」「0なら安全」という一律の判断は避けます。⁸

検証環境では、WebAuthnのセキュアコンテキスト要件とRP IDの要件を分けて確認します。通常はHTTPSが必要で、開発用にはhttp://localhostを使えます。http://127.0.0.1が信頼できるオリジンとして扱われることと、IPアドレスをRP IDにできることは別です。WebAuthnのRP IDにはドメイン名の条件があるため、開発時もlocalhostなど、利用するブラウザーが受け入れる構成で検証してください。そこで作った資格情報を本番ドメインへそのまま持ち込むことはできません。⁹²⁵

10. Windowsや社内システムでは何を確認するか

Windowsでは、「Windows Helloの画面が出た」という観察だけで、パスキーの保存先や同期の有無まで判断しないことが重要です。Windows Helloによるユーザー検証と、Microsoftや他社の資格情報マネージャーへの保存・同期は、分けて確認する項目です。ローカルに保存するパスキーも、同期プロバイダーに保存するパスキーもあります。²⁶

flowchart TB
        accTitle: Windowsでパスキーを導入するときの確認順序
        accDescr: ログイン対象、資格情報の保存先、組織の許可ポリシー、紛失時の回復を順に分けて確認します。
        A["何へログインするか"] --> B["Webサービス・Entra ID・Windowsを区別"]
        B --> C["パスキーの保存先と同期の有無を確認"]
        C --> D["認証方法ポリシーと認証強度を確認"]
        D --> E["予備の鍵と紛失時の手順を検証"]

図14: 同じWindows Helloの画面でも、ログイン対象や保存先によって運用上の意味は変わります。

Windows Helloのローカルコンテナーに保持する資格情報は、同期型の保管庫とは異なります。TPMを利用するWindows Helloの構成では、TPMによる鍵の保護が重要な役割を担います。ただし、パスキー一般の分類とTPMの有無を同一視せず、実際の保存先・端末・組織の要件で判断します。²⁷²⁸

Microsoft Entra IDでは、パスキーの利用を許可する認証方法ポリシーと、対象リソースでどの強さの認証を求めるかという条件付きアクセスの認証強度を分けて設計します。パスキーを登録できる状態にしただけでは、すべてのアクセスが自動的にフィッシング耐性MFAに限定されるわけではありません。同期型を含め、許可するパスキーの種類は最新の対応状況と組織のポリシーで確認します。²⁹

社内Webアプリを直接WebAuthn対応させるなら、HTTPS、証明書、名前解決、安定したRP IDとなるドメイン名を先に整えます。認証基盤へ処理を委ねる構成なら、アプリ側はその基盤との連携とセッション管理を設計します。WinForms/WPFアプリでEntra IDを使う話と、アプリ自身がWebAuthnのRPになる話も同じではありません。

また、パスキーはSMB共有への認証を自動的に置き換えたり、NTLMやKerberosの問題を直接直したりする機能ではありません。何のログインを変えるのかを決め、まず小さな対象で登録・認証・紛失・回復を試すことが、業務を止めない導入につながります。

11. まとめ ── 秘密を渡さないことと、周辺を守ることはセット

パスキーの強さは、ログイン先へ秘密鍵を渡さず、今回の要求と使用先に結び付いた署名で認証する点にあります。公開鍵の流出だけでは正しい署名を作れず、無関係な偽サイトから本物用の資格情報を使うこともできません。

その一方で、同期型の保管庫、端末のロック、代替ログイン、回復手順、ログイン後のセッションは守り続ける必要があります。パスキーに変えると不要になる対策と、引き続き必要な対策を分けるのが、導入を正しく評価するための視点です。

利用者なら、保存先と回復手段を確認し、重要なアカウントには独立した予備を用意する。導入する側なら、サーバーでの検証と複数パスキーの管理、失効・回復を一つの機能として設計する。そこまで含めることで、便利さとフィッシング耐性を実際の運用につなげられます。

関連記事

• WindowsのTPMとは何か ── 図解でわかる「鍵を外に出さない金庫」と測定起動
• 図解でわかるNTLMとKerberos ── なぜ認証はNTLMに「落ちる」のか
• WinForms/WPFアプリにEntra ID認証を組み込む ── MSAL.NETとWAMブローカーの実務構成
• PowerShellでの資格情報の安全な扱い ── 平文パスワードをスクリプトから追放する
• Windowsアプリ開発のセキュリティ最低限チェックリスト
• 中小企業のセキュリティ対策、何から始めるか ── IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版の歩き方

関連する相談領域

合同会社小村ソフトでは、社内Webシステムの認証機能の見直し、Entra IDとの連携、WinForms/WPFなどWindows業務アプリへの認証組み込みを含む受託開発を扱っています。パスキー対応を検討する際も、ログイン画面だけでなく、利用端末・既存認証基盤・回復手順を合わせて整理します。

参考リンク

仕様と製品情報は2026年9月8日時点で確認しています。ブラウザー・OS・テナントの設定によって利用できる機能は異なります。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

パスキーはなぜパスワードより安全なのですか？

ログイン先へ秘密鍵を渡さず、今回のチャレンジと使用先に結び付いた署名で認証するためです。公開鍵だけの流出では署名を偽造できず、無関係な偽サイトから本物用のパスキーを使うこともできません。ただし、サーバーでの適切な検証と、端末・回復手段・セッションの保護は必要です。

指紋や顔の情報はサイトへ送られますか？

WebAuthnの認証応答に指紋画像や顔の特徴量を載せてログイン先へ送ることはありません。生体認証やPINは利用者側で秘密鍵の使用を許可するために使い、サービス側は署名やユーザー検証の結果を確認します。

秘密鍵を送らないのに、パスキーを同期できるのはなぜですか？

ログイン先への認証と、資格情報マネージャーの同期は別の経路だからです。同期型は秘密鍵を暗号化して端末間に複製しますが、ログイン先へ秘密鍵を渡すわけではありません。同期保管庫の解除・復旧条件は製品や設定によって異なります。

スマホを失くしたら、パスキーを使っているアカウントはどうなりますか？

同期型では保管庫の復旧条件を満たせば別端末で使える場合があり、固定型では別途登録した予備の資格情報や回復手段が必要です。端末の保護や紛失の届け出と並行して安全な回復手段を確認し、危険な資格情報の失効と既存セッションの終了を別々に行います。同期された同じ資格情報をサービス側で失効させると、他端末のコピーもそのサービスへログインできなくなります。

パスキーならフィッシング対策は不要ですか？

不要にはなりません。パスキーは偽ドメインへの資格情報の受け渡しに強い一方、パスワードやSMSへの切り替え誘導、回復手続きの悪用、端末やセッションの侵害は別途対策が必要です。

Windows Helloで使うパスキーは必ず端末固定ですか？

Windows Helloの確認画面だけでは保存先や同期の有無を判断できません。ローカルコンテナーの資格情報と、同期プロバイダーに保存するパスキーを区別し、実際の保存先・端末・組織ポリシーを確認します。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。