パスキー2026 - 同期・端末間認証・復旧を正しく理解する

中級 | 8分 で読める | 2026.04.19

公式ドキュメント
AuthSecurity

2026年のパスキーをどう理解するか

記事情報: 2026年4月19日初出。本文の仕様・対応状況は2026年7月25日に公式資料で再確認しています。

パスキーは、WebAuthnと公開鍵暗号を利用する認証方法です。サービスには公開鍵を保存し、利用者の端末やcredential providerが秘密鍵を管理します。

パスワードのように共有秘密をサーバーへ送らないため、正しいRP IDとoriginに結び付いた認証を行えます。フィッシング耐性を持つ一方で、アカウント復旧、端末変更、複数credentialの管理はサービス側で設計する必要があります。

2026年7月25日時点では、「Apple・Google・Microsoftの3社間で、すべてのパスキーが自動的に自由同期される」と理解するのは正しくありません。同期、別端末認証、import・exportは異なる仕組みです。

パスキーの基本

登録時には、authenticatorがcredential key pairを作ります。

  • 秘密鍵：authenticatorまたはcredential provider側で管理
  • 公開鍵：サービス側に保存
  • credential ID：登録したcredentialを識別
  • RP ID：credentialを利用できるサービスの範囲

ログイン時は、サーバーが生成したchallengeに対してauthenticatorが署名します。サーバーは保存済みの公開鍵で署名を検証します。

登録:
サービス → challenge → authenticator
サービス ← 公開鍵・credential ID ← authenticator

認証:
サービス → challenge → authenticator
サービス ← 署名 ← authenticator

WebページのJavaScriptが秘密鍵を受け取ることはありません。ブラウザとOSがauthenticatorとの処理を仲介します。

「同期」と「別端末認証」は違う

同じ管理サービスを通じて複数端末でパスキーを使う同期と、スマートフォンで認証して秘密鍵をPCへコピーしない別端末認証を比較した概念図

同期されるパスキー

syncable passkeyは、credential providerの仕組みを通して、同じ利用者の複数端末で使えるように管理されます。たとえば各OSやパスワードマネージャーが提供する同期機能があります。

同期の範囲、暗号化、利用可能なOS、組織アカウントでの制限はproviderによって異なります。サービス開発者が秘密鍵をコピーする仕組みではありません。

端末に固定されたcredential

セキュリティキーや端末内の保護領域で管理され、別端末へ同期されないcredentialもあります。高い保証が必要な用途では、組織の要件に応じてattestationやauthenticator policyを検討します。

cross-device authentication

PCでログインするときにスマートフォンを使う方法は、秘密鍵をPCへ同期することと同じではありません。QRコードや近接確認を使い、credentialを持つスマートフォンが認証処理を行います。

したがって、「別の端末でログインできた」ことだけで「3社間同期が完了した」と判断してはいけません。

WebAuthn Level 3

W3Cは2026年5月26日にWebAuthn Level 3のCandidate Recommendation Snapshotを公開しました。Candidate Recommendationは標準化プロセス上の段階であり、すべてのブラウザが全機能を同時に実装済みという意味ではありません。

Level 3には、実装を扱いやすくするAPIや、関連origin、credential管理に関する更新が含まれます。実際に利用する前に、対象ブラウザの対応状況を確認します。

たとえばPublicKeyCredential.getClientCapabilities()に対応する環境では、clientが報告する機能を確認できます。ただし、未対応環境へのfallbackが必要です。

if (
  typeof PublicKeyCredential !== "undefined" &&
  "getClientCapabilities" in PublicKeyCredential
) {
  const capabilities =
    await PublicKeyCredential.getClientCapabilities();
  console.log(capabilities);
}

feature detectionの結果だけで認証を許可せず、サーバー側では従来通りchallenge、origin、RP ID、署名、counterなど必要な検証を行います。

登録時にサーバーが行うこと

パスキー登録では、サーバーがランダムなchallengeを発行し、短い有効期限でセッションへ結び付けます。

const options = {
  challenge,
  rp: {
    id: "example.com",
    name: "Example",
  },
  user: {
    id: userIdBytes,
    name: "student@example.com",
    displayName: "Student",
  },
  pubKeyCredParams: [
    { type: "public-key", alg: -7 },
    { type: "public-key", alg: -257 },
  ],
  authenticatorSelection: {
    residentKey: "required",
    userVerification: "required",
  },
};

challengeとuser.idは、固定文字列ではなく適切なbyte列として扱います。登録レスポンスを受け取ったサーバーは、少なくとも次を検証します。

  • challengeが発行した値と一致する
  • originが許可したoriginと一致する
  • RP ID hashが期待値と一致する
  • credential public keyを正しく取り出せる
  • 同じcredential IDを重複登録していない
  • user verificationの結果が要件を満たす

暗号処理を独自実装せず、保守されているWebAuthn server libraryを利用します。

認証時にサーバーが行うこと

認証時も新しいchallengeを発行します。署名の検証だけでなく、登録した利用者とcredentialの関係を確認します。

  • challenge
  • origin
  • RP ID hash
  • signature
  • user verification flag
  • credential IDとuserの対応
  • 必要に応じてsign counter

失敗理由を細かく表示しすぎると、登録済みアカウントの推測に使われる場合があります。利用者向けメッセージと、運営者向けログを分けます。

アカウント復旧

パスキーを導入しても、端末の紛失、provider accountへアクセスできない状況、組織からの退職は起こります。

安全な設計では、1人の利用者が複数のパスキーを登録できるようにします。

利用者
├── 個人スマートフォンのパスキー
├── PCのパスキー
└── 予備のセキュリティキー

管理画面では、登録日時、利用者が付けた名前、最終使用日時を表示し、不要なcredentialを削除できるようにします。ただし、最後のcredentialを削除する前には代替のログイン方法を確認します。

メールだけの復旧を用意すると、パスキーより弱い経路がアカウント全体の弱点になる可能性があります。本人確認、待機時間、既存端末への通知、サポート担当者の権限を含めて設計してください。

段階的な導入

既存のパスワード利用者を一度に強制移行させる必要はありません。

  1. ログイン済み利用者へパスキー追加を案内する
  2. 登録直後に再認証を試す
  3. 複数credentialを登録できるようにする
  4. 利用状況と失敗原因を計測する
  5. 復旧手順とサポート手順を検証する
  6. 代替認証を縮小する条件を決める

Appleはautomatic passkey upgradesや管理endpointを案内し、GoogleもAndroid・Web・iOS向けの実装ガイドを公開しています。ただし、OSやブラウザごとに提供時期と条件が異なるため、対象環境で確認します。

セキュリティ上の注意

  • WebAuthnはHTTPSのsecure contextで利用する
  • challengeを予測不能にし、使い回さない
  • originとRP IDを厳密に検証する
  • credential IDを利用者と結び付けて保存する
  • ログへchallengeや認証レスポンス全体を不用意に残さない
  • パスキー追加・削除時に本人確認と通知を行う
  • fallback認証をパスキーより弱いまま放置しない

パスキーはフィッシング耐性を高めますが、セッション窃取、端末上のマルウェア、アカウント復旧を狙う攻撃まで自動的に解決するものではありません。

まとめ

  • パスキーはWebAuthnと公開鍵暗号を利用する
  • provider内の同期とcross-device authenticationは別の仕組み
  • 3社間ですべての秘密鍵が自由同期されるわけではない
  • WebAuthn Level 3は2026年5月時点でCandidate Recommendation
  • 複数credentialと安全な復旧手順を設計する
  • server libraryを使い、challenge・origin・RP ID・署名を検証する

参考リソース

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR