パスキー・WebAuthn 2026 — FIDO2・Auth0・Clerk・Stytch・Logto・SuperTokens・Hanko 深掘りガイド

プロローグ — 2026 年、パスワードの終焉が本当に始まった

2022 年 5 月に Apple・Google・Microsoft が「パスキーを採用する」と共同発表したとき、多くの人は半信半疑だった。「またその話か。OAuth 2.0 だって普及まで 10 年かかった」が典型的な反応だった。ところが 2026 年 5 月現在、本当に変わったものが見える。

米国政府ログインポータルの Login.gov がパスキーを第一認証として追加した。
Apple Passwords アプリが iOS 18 / macOS Sequoia で一級市民として分離された。iCloud キーチェーンの後継だが UX が完全に違う。
Android 15 Credential Manager がパスキーとパスワードを単一 API で統合した。
1Password / Bitwarden / Dashlane がクロスプラットフォームのパスキー同期を正式に支援する。
WebAuthn Level 3 が 2024 年 9 月に W3C 勧告となった。Conditional UI(自動補完のように見えるパスキー選択)が標準の一部だ。
Hybrid transport(caBLE → CTAP 2.2) によりデスクトップで電話を認証器として使うシナリオが安定した。

本記事は 2026 年 5 月時点のパスキーと WebAuthn エコシステムの地図を描く。ユーザー視点・開発者視点・運用者視点の三つをすべて扱う。標準スタックから始めて、プラットフォーム UX(iOS・Android)、認証 SaaS(Auth0・Clerk・Stytch・SuperTokens・Logto・Hanko・Passage)、韓国と日本の事業者状況、そして既存パスワードシステムから段階的に移行する戦略までを押さえる。

コード例は意図的に @simplewebauthn/server と @simplewebauthn/browser を標準リファレンスとして使う。Node 陣営の事実上の標準であり、他の SaaS も内部的には同じ形の API を露出している。

第 1 章 · 2026 年パスワードの終焉 — どこまで来たか

2022 年の発表から 4 年で何が変わったか。意味のある変化を 5 つだけ並べる。

第一に、OS レベルでの一級市民化。 iOS 17 まではパスキーは iCloud キーチェーンの下位機能だった。iOS 18 で Passwords アプリが分離されたことで、ユーザーに「パスキーはパスワードよりよい」という明確なシグナルが届いた。Android 15 も Credential Manager API で同じ統合を行った。

第二に、クロスプラットフォーム同期。 パスキーの弱点は「ひとつの生態系に閉じ込められる」だった。2024-2025 年の間に 1Password・Bitwarden・Dashlane が皆パスキー同期を支援することで、この問題が解けた。iCloud で作ったパスキーを Windows でも 1Password で使える。

第三に、Conditional UI。 WebAuthn Level 3 の最重要機能。ログインフォームのユーザー名欄をクリックすると、自動補完のようにパスキー候補が出てくる。ユーザーは別のボタンを押す必要がない。この UX のおかげで「パスキー = 馴染みのある自動補完」と認識されるようになる。

第四に、Hybrid transport。 デスクトップブラウザで電話のパスキーを使うシナリオ。QR コードを出して、電話で読み取り、BLE で近くにいるかを確認する。CTAP 2.2 仕様に正式に組み込まれた。

第五に、政府・金融分野の採用。 Login.gov がパスキーを受け入れ始め、米国 SSA が続いている。日本は 2025 年にマイナンバーカードとパスキーを連動する実証を始めた。韓国は PASS・金融認証書陣営がまだ強いが、一部の大手テックが動いた。

残る課題もある。

アカウント復旧: すべての端末を失った場合の復旧手段。まだ標準がなく、事業者ごとに違う。
ユーザー教育: 「パスキーとは何か」を説明するコストはまだ大きい。
レガシー互換性: パスワードマネージャ・SMS OTP・2FA アプリが同時に存在し、ユーザーが混乱する。
B2B / SCIM: エンタープライズでパスキーポリシーを IdP レベルで管理するシナリオは始まったばかり。

これらの課題は記事の後半で再度取り上げる。

第 2 章 · WebAuthn / FIDO2 / CTAP — 標準スタックの整理

用語が紛らわしい。一行でまとめる。

FIDO2 = WebAuthn(W3C) + CTAP(FIDO Alliance) の 2 つの標準を束ねる名前。
WebAuthn = ブラウザとサーバー間の JavaScript API。navigator.credentials.create() / .get()。
CTAP = ブラウザと外部認証器の間のワイヤープロトコル。CTAP 1(U2F)、CTAP 2.0、2.1、2.2。
Passkey = WebAuthn credential のうち「同期され、発見可能(Discoverable)」なものに対するマーケティング名。技術的には resident key + multi-device。

図にするとこうなる。

[ユーザー ブラウザ/アプリ]
   |  WebAuthn JS API (navigator.credentials)
   v
[OS Credential Provider]  (iOS Passwords / Android Credential Manager / Windows Hello)
   |  CTAP 2.x (USB-HID, NFC, BLE/caBLE)
   v
[認証器]  (Secure Enclave / TPM / Titan / YubiKey / iPhone / Android phone)

WebAuthn API の核心は 2 つの関数だ。

// 1) 登録(Registration) — 新しいパスキーを生成
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,            // サーバーから来たランダム nonce
    rp: { id: 'example.com', name: 'Example' },
    user: {
      id: new Uint8Array(userIdBytes),     // サーバー側 user.id (UTF-8 bytes)
      name: 'alice@example.com',
      displayName: 'Alice',
    },
    pubKeyCredParams: [
      { type: 'public-key', alg: -7 },     // ES256
      { type: 'public-key', alg: -257 },   // RS256
    ],
    authenticatorSelection: {
      residentKey: 'required',             // = passkey
      userVerification: 'preferred',
    },
    attestation: 'none',                   // 多くのコンシューマサービスは none
  }
})

// 2) 認証(Authentication) — 既存のパスキーでログイン
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: serverChallenge,
    rpId: 'example.com',
    userVerification: 'preferred',
    // allowCredentials が空なら Discoverable credential 選択 UI
    allowCredentials: [],
  },
  mediation: 'conditional', // ← Conditional UI を有効化
})

サーバー側で検証すべきことは次のとおり。

検証項目	意味
challenge 一致	サーバーが送った challenge が応答に含まれるか
origin 一致	clientDataJSON.origin が RP origin か
rpIdHash 一致	authenticatorData.rpIdHash が RP id の SHA-256 か
flags.UP / UV	User Present / User Verified ビット
signCount	counter が単調増加しているか(クローン検出)
署名検証	clientDataJSON と authenticatorData を合わせて公開鍵で検証

これを自分で実装すると 100% 失敗する。だからほぼ全員ライブラリを使う。次章で見る。

第 3 章 · iOS 18 + macOS Sequoia Passwords アプリ — Apple の一手

2024 年 9 月の iOS 18 発表で最も静かに、しかし最も意味のあった変化が Passwords アプリだった。iCloud キーチェーンは元々 Settings の中に埋まっていたが、これを独立アプリとして切り出すことでユーザーから明確に「パスワードマネージャ」として見えるようになった。

ポイント。

独立アプリ: Spotlight・Dock・ホーム画面から直接アクセス。macOS・iOS・iPadOS・visionOS・Windows(iCloud for Windows)同期。
カテゴリ分割: Passwords / Passkeys / Wi-Fi / Verification Codes(TOTP) / Security 推奨。パスキーが独立カテゴリ。
共有グループ: 家族・チームとパスキーを共有。パスワード共有の後継。
Verification Codes 統合: 既存の 6 桁 OTP も同じアプリが入力する。別の Authenticator アプリの存在感が薄れる。
Security 推奨: 弱いパスワード・使い回し・流出データセットの一致を通知。

ユーザー導線は次のとおり。

1. Safari で example.com に登録
2. フォーム入力中に "Passwords" が自動提案
3. ユーザー: Face ID 一度
4. → パスキー登録完了、iCloud Keychain に保存
5. 他端末(Mac/iPad)でそのまま同じアカウントにログイン可能

開発者視点で知っておくべき点。

Associated Domains: ネイティブ iOS アプリがパスキーを使うには apple-app-site-association ファイルに webcredentials ドメインを登録する必要がある。
AutoFill 連携: ASAuthorizationPlatformPublicKeyCredentialProvider でフォーム自動補完。SwiftUI では .textContentType(.username) + .authorizationController()。
Same Sign-in Account: 同一 Apple ID でログインしたすべての端末にパスキーが自動同期。iCloud Keychain の E2EE モデルそのまま。
共有グループ: iOS 18 から ASCredentialIdentityStore がグループ共有パスキーを露出する。

注意点として attestation はほぼないこと。Apple Anonymous Attestation は提供されるが、多くのコンシューマサービスは attestation: 'none' を受け入れるのが正常だ。強い attestation が必要なのはエンタープライズ・政府・金融分野だけ。

第 4 章 · Android 15 Credential Manager — パスキーとパスワードの統合

Google は Android で認証 API が断片化しすぎているのを整理するために Credential Manager を作った。Android 14 でベータ、Android 15 で GA。中心アイデアは「パスワード・パスキー・フェデレーションログイン(Google Sign-In)を 1 つの API に」。

// Android Credential Manager — 登録
val request = CreatePublicKeyCredentialRequest(
  requestJson = serverChallengeJson,
  preferImmediatelyAvailableCredentials = true,
)
val credential = CredentialManager.create(context)
  .createCredential(activity, request)

// 認証
val getRequest = GetCredentialRequest(
  credentialOptions = listOf(
    GetPublicKeyCredentialOption(serverRequestJson),
    GetPasswordOption(),  // 既存のパスワードも同時に露出
  ),
)
val response = CredentialManager.create(context)
  .getCredential(activity, getRequest)

利点ははっきりしている。

単一エントリーポイント: ユーザーが「パスキーかパスワードか」を知らなくてもログインできる。
サードパーティ提供者: 1Password・Bitwarden・Dashlane が OS レベルで同じダイアログに露出する。
Digital Asset Links: ウェブドメインとアプリを紐づける標準。assetlinks.json に delegate_permission/common.get_login_creds を宣言すれば、同じパスキーをアプリ・ウェブの両方で使える。

WebAuthn 標準との違い。

Android の requestJson は WebAuthn JSON encoding 標準(W3C PublicKeyCredential.toJSON())をそのまま追従する。つまりサーバーは WebAuthn ライブラリをそのまま使える。
mediation: 'conditional' に該当するのが preferImmediatelyAvailableCredentials = true だ。

第 5 章 · 1Password / Bitwarden / Dashlane — クロスプラットフォームパスキー同期

OS 陣営(Apple Keychain・Google Password Manager)の同期はひとつの生態系内でしか機能しない。だから サードパーティのパスワードマネージャの役割が大きくなった。2024-2025 年の間に主要 3 社が皆パスキー同期を支援している。

1Password。

2023 年 6 月にパスキー作成・保存をサポート、2024 年から同期が安定。
Windows・macOS・Linux・iOS・Android・ウェブブラウザ拡張。Linux で Apple Keychain パスキーが使えないユーザーに最も魅力的。
2024 年に Passage(passage.id)を買収。自社の認証 SaaS に呼び込む戦略。
Watchtower でパスキー対応サイトを推奨。

Bitwarden。

オープンソース(OSS)。セルフホスト可能(vaultwarden は非公式だが人気)。
2023 年 11 月にブラウザ拡張でパスキー保存開始。2024 年にモバイルに拡張。
無料プランでもパスキー機能を制限なく使えるのが強み。

Dashlane。

2022 年 9 月に最も早くコンシューマ向けパスキー発表。マーケティング面では先頭だった。
2024 年からエンタープライズラインナップ強化。SCIM 統合・SSO ルーティング。
Confidential SSO(クライアントサイド E2EE)で差別化。

3 社の共通点は WebAuthn Conditional UI を正確に実装していること。ブラウザ拡張が OS の credential provider と競合せず、ユーザーがどちらを使うか選べるようになっている。

第 6 章 · WebAuthn Level 3(2024.9 W3C 勧告)— Conditional UI / Auto-fill

WebAuthn Level 2 が 2021 年に W3C 勧告となり、Level 3 が 2024 年 9 月に最終勧告となった。主な変化を 5 つ。

1. Conditional UI(Auto-fill)。

// ページ読み込み時点で先に呼ぶ。mediation: 'conditional' が核心。
const cred = await navigator.credentials.get({
  publicKey: {
    challenge: serverChallenge,
    rpId: 'example.com',
    allowCredentials: [],          // 空でなければ Discoverable 候補検索にならない
  },
  mediation: 'conditional',
  signal: abortController.signal,
})

ユーザーがログインフォームの username 入力(autocomplete="username webauthn")にフォーカスすると、自動補完のようにパスキー候補が出る。
ユーザーが別途「パスキーでログイン」ボタンを押す必要がない。
iOS Safari・Chrome・Edge・Firefox がすべて対応する。

2. JSON encoding。 PublicKeyCredential.toJSON() の標準化。サーバーが ArrayBuffer を直接扱わず JSON で受け取る。

3. PRF extension。 Pseudo-Random Function 拡張。パスキーから決定論的秘密(例: E2EE 鍵)を導出できる。1Password がこれで vault の解錠を試みる PoC を見せた。

4. largeBlob の安定化。 認証器に小さなデータ(例: ユーザー定義ラベル)を一緒に保存。

5. attestation の直接形式。 Apple/Google がより多くの attestation 形式を標準に合流させた。

第 7 章 · Hybrid transport(caBLE → CTAP 2.2)— phone-as-authenticator

「ノート PC でウェブサイトにログインするが、パスキーは電話にある」というシナリオが最もよくあるペインポイントだった。2022 年から caBLE(Cloud Assisted Bluetooth Low Energy) という名前で実験され、2024 年に CTAP 2.2 仕様で Hybrid transport という正式名になった。

導線。

1. PC ブラウザが QR コードを表示
2. ユーザーが電話カメラでスキャン
3. 電話がクラウドでハンドシェイク (Apple/Google プッシュインフラ)
4. 電話と PC が近くにいるかを BLE 信号で確認
5. 電話で Face ID/Touch ID/指紋
6. 電話が署名を作り、クラウド経由で PC に渡す
7. PC がその署名を RP サーバーへ送付 → ログイン成功

この導線のセキュリティモデルが興味深い。

BLE proximity: クラウド経由のリレーだけでは不十分なので、BLE で「物理的に近いか」を確認する。
End-to-end encryption: QR コードに一時的な ECDH 公開鍵が入っていて、電話と PC がそのキーで直接 E2EE チャネルを作る。Apple/Google クラウドは暗号化されたトラフィックしか見られない。
One-shot: 一度使えば終わり。永続的なペアリングではない。

なぜよいか。

Windows PC でも iPhone パスキーを使える。
Mac で Android phone のパスキーを使える。
他人の PC(例: ネットカフェ)でも安全。

弱点。

BLE を有効にしないと使えない。会社のセキュリティポリシーで BLE を切ったノート PC では不可。
1 回あたり 30 秒〜60 秒かかる。Conditional UI より遅い。

第 8 章 · Auth0 / Okta — エンタープライズ陣営

大企業がパスキーを導入する際に最初に思い浮かべるのが Auth0/Okta だ。両者ともパスキーを正式に支援する。

Auth0(Okta 子会社)。

Database connections で「Passkey」を切り替えるとパスキーログインが可能になる。Universal Login に統合。
"Progressive profiling" ワークフローと結合可能。最初の登録はパスキーで、後で追加情報を収集。
料金: B2C は MAU 基準、B2B はシート基準。パスキー自体は追加課金なし。

Okta Workforce Identity Cloud。

従業員向け IdP。SCIM・SAML・OIDC・MFA・ポリシーエンジン。
2024 年に Okta FastPass にパスキー統合。ユーザー端末に登録されたパスキーを IdP レベルでポリシー管理する。
Yubikey・Windows Hello・Touch ID 同時サポート。

Microsoft Entra ID(旧 Azure AD)。

同カテゴリだが Microsoft 生態系の束。Entra がパスキーを支援し、Authenticator アプリと統合。
社内 Windows 端末で Hello for Business と滑らかに連携。

この陣営の共通の強みは ガバナンス。パスキーポリシーをユーザーでなく IT が管理する。

どの attestation を受け入れるか(例: FIPS 認定キーのみ)
どの端末に登録できるか
紛失時にどう再発行するか

コンシューマ SaaS はあまり扱わない部分だ。

第 9 章 · Clerk / Stytch / Passage — 開発者フレンドリー SaaS

スタートアップ・開発者陣営では別の種類の SaaS が人気だ。

Clerk。

2020 年創業。Next.js と React 生態系に最適化。<SignIn />、<UserButton /> のようなコンポーネントが即動く。
パスキーは 2024 年から正式サポート。clerkClient.users.createPasskey() API と自動 UI。
多重セッション・organizations・invitations のような SaaS パターンが即動く。
料金: MAU 基準。無料 10K MAU。

// Clerk — Next.js 例(概念)
import { SignIn } from '@clerk/nextjs'

export default function Page() {
  return <SignIn signInUrl="/sign-in" />
  // パスキー・メール・OAuth が自動で露出する
}

Stytch。

2020 年創業。Plaid 出身の創業者。API-first 強調。
B2C は Frontend SDK + Backend SDK の組み合わせ。B2B(Stytch B2B)は SCIM・SSO ルーティングが別。
パスキーは 2023 年から正式。M2M トークンまで含むフルスタック。
「Passwordless」シナリオ(Magic Link + Passkey)に集中。

Passage(1Password 買収)。

2022 年創業。パスキー専用 SaaS として出発。
2024 年 1 月に 1Password が買収。以後パスキー + 1Password vault 統合シナリオへ方向転換。
無料プランが寛容(10K MAU 無料)。
React/JavaScript/Next.js SDK が充実。

3 社の共通点。

Conditional UI 自動有効化: ユーザーが username 入力欄を作ると自動補完が動く。
アカウント復旧導線: パスキー紛失時にマジックリンク・OTP でフォールバック。
Drop-in UI vs Headless: 2 つのモードをサポート。デザインを制御したいなら Headless。

第 10 章 · Logto / SuperTokens / Hanko — オープンソースの選択肢

セルフホストが必要なチーム、GDPR / データ主権の問題があるチーム、料金を制御したいチームにはオープンソースの選択肢がある。

SuperTokens。

2020 年創業。Y Combinator。MIT ライセンス。
コアサービス + Node/Python/Go バックエンド SDK + React / プレーン JS フロントエンド SDK。
「recipe」概念: passwordless・password・third-party・MFA を組み合わせる。
パスキーは 2024 年から正式。セルフホスト可能。
料金: OSS は無料。Managed(SuperTokens Cloud)は MAU 基準。

// SuperTokens — passkey recipe(概念)
import Passkey from 'supertokens-node/recipe/passkey'

SuperTokens.init({
  recipeList: [
    Passkey.init({
      // RP 情報・challenge 生成・検証をライブラリが担当
    }),
    Session.init(),
  ],
})

Logto。

2022 年創業。中国・アジア市場で強い。Apache 2.0。
Customer Identity(CIAM)に特化。多言語・SSO・ソーシャルログイン。
セルフホストと Logto Cloud の両方を提供。
パスキーは 2024 年に正式サポート。WebAuthn Level 3 互換。

Hanko。

2022 年創業。ドイツの会社。EU データ主権メッセージを強調。
AGPL + 商用デュアルライセンス。Hanko Cloud。
「Passkey-first」がスローガン。パスキーを default、パスワードをフォールバックとするポリシーを強制。
Drop-in UI(「hanko-elements」)が綺麗。

<!-- Hanko — drop-in コンポーネント(概念) -->
<hanko-auth></hanko-auth>
<script type="module">
  import { register } from '@teamhanko/hanko-elements'
  register({ shadow: true })
</script>

オープンソース陣営の共通の強み。

セルフホスト可能: データを自社インフラに置ける。
lock-in 回避: 料金ポリシー変更リスクが小さい。
監査可能: コード自体を読んで検証できる。

弱点。

運用負担: DB・セッションストレージ・キーローテーションを自分で管理。
UX ポリッシュの差: SaaS ほど滑らかでないこともある。
コンプライアンス認証: SOC 2・ISO 27001 を自社インフラに適用する必要がある。

第 11 章 · 韓国 — Naver / Kakao / Toss パスキー導入

韓国はパスキー導入がグローバル平均より遅い。理由は 2 つ。第一に 金融認証書・共同認証書・PASS という独自認証エコシステムが強い。第二に 金融分野の ARS・OTP 依存が深い。

Naver。

2024 年 10 月に「Naver Passkey」ベータ。Naver アプリで発行し、ウェブでログイン。
2025 年に一部ユーザーへデフォルトオプションとして露出。
Naver Series(Whale・WORKS・Naver Pay)入口で利用される。

Kakao。

KakaoTalk 認証と Kakao アカウント認証の統合作業。パスキーは 2025 年初にベータ。
セキュリティ強度の高い一部サービス(KakaoBank・Kakao Pay)は依然 PIN + 生体認証。
Kakao i Cloud ユーザーに限ってパスキー同期。

Toss。

Toss 認証書で独自認証エコシステムを構築済みで、パスキー導入には慎重。
2025 年末からパスキーを PoC。正式導入は 2026 年後半の予定。
Toss Payments で加盟店オーナー用ダッシュボードのパスキーが先に入った。

公共・金融。

PASS(通信 3 社) は自社エコシステム維持中。パスキー直接導入より PASS 内で FIDO を使う方向。
金融認証書(2020 民間認証導入) は金融決済院インフラ。パスキーとは異なる技術スタックだがユーザー体験は類似。
モバイル身分証(2024) は DID ベース。パスキーとは別標準だが同じ「共有鍵」フローを持つ。

示唆。

韓国は認証市場が断片化しており、パスキーが定着するまで時間がかかる。
B2C サービスはパスキーを「韓国ユーザー向けの選択肢」程度で導入するのが現実的。
B2B SaaS の韓国進出時は SAML/OIDC + パスキーを両方露出するのが安全。

第 12 章 · 日本 — docomo / au / SoftBank ID・Yahoo!Japan

日本は韓国より認証標準化がやや進んでいる。通信キャリア ID とマイナンバー、そして LINE/Yahoo! の戦略が噛み合っている。

docomo ID。

2024 年にパスキーベータ。d アカウントの一部として統合。
d 払い・d カードのような決済認証に拡大中。

au ID(KDDI)。

2024 年後半にパスキー正式サポート。au PAY 決済で利用。

SoftBank ID / Y!mobile。

LINE ヤフーが買収後、Yahoo!Japan ID との統合を進行。パスキーはその統合作業の一つの軸。

Yahoo!Japan。

2022 年から試験的にパスキーを導入した日本最大の事例。最も早い開始。
2024 年時点で数千万ユーザーがパスキーを保有。
運用事例が最も豊富で、日本国内でリファレンスとして引用される。

LINE。

2023 年から LINE Login にパスキー。日本・タイ・台湾で急速展開。
LINE Pay 決済認証に適用。

マイナンバーカード。

日本政府のデジタル ID。元々マイナポータルでカード + PIN 認証。
2025 年からマイナンバーカードの証明書をパスキー形式で露出する実証。

日本の特徴は 通信キャリア・プラットフォームがパスキー導入に積極的な点。政府もマイナンバーカードを通じて互換性をまとめている。

第 13 章 · パスキー移行戦略 — 段階的導入の方法

既存パスワードシステムがあるサービスにパスキーをどう差し込むか。5 段階で整理する。

ステップ 1: パスキー登録をオプションで追加。

ログイン後の「セキュリティ設定」で「パスキー登録」を露出。
既存パスワードユーザーが追加認証手段としてパスキーを登録。
1 ユーザーあたり複数のパスキー登録が可能(デスクトップ・電話・iPad)。

ステップ 2: ログインフォームに Conditional UI を追加。

username 入力に autocomplete="username webauthn"。
ページ読み込み時に navigator.credentials.get({ mediation: 'conditional' })。
パスワードユーザーは影響なし。パスキーユーザーだけ自動補完のように候補が出る。

ステップ 3: 新規登録でパスキーをデフォルトに。

新規ユーザーに「パスワードの代わりにパスキー」オプションをデフォルト提示。
ユーザーが明示的に拒否したらパスワード。
フォールバックはメールマジックリンク。

ステップ 4: 既存パスワードユーザーへのアップセル。

ログイン時に「次回からパスキーでもっと速くログインしますか?」
A/B テストで conversion をモニタリング。(通常 20-40% 転換。)
柔らかく勧めるが強制はしない。

ステップ 5: パスキー単独オプションの登場。

ユーザーがオプションで「パスワードを無効化」できるように。
政府・金融分野コンプライアンスが許す範囲内で。

アカウント復旧シナリオ — 最も重要な部分。

すべての端末を失ってもアカウントに入れる方法が必要。
メールマジックリンク・SMS OTP・復旧コード(recovery codes)・本人確認。
「パスキー = より安全」だが「パスキー = 復旧不能」では採用は失敗する。

メトリクス。

パスキー登録率(登録ユーザーのうちパスキーを登録した比率)
パスキーログイン比率(ログインのうちパスキーを使った比率)
パスキー認証成功率(試行に対する成功)
パスキーフォールバック率(失敗してパスワードへフォールバックした比率)

この 4 つを見ながら、段階的にパスワードの比重を減らしていく。

第 14 章 · 参考 / References

標準 / 仕様。

W3C WebAuthn Level 3 — https://www.w3.org/TR/webauthn-3/
W3C WebAuthn Level 2 — https://www.w3.org/TR/webauthn-2/
FIDO Alliance CTAP 2.2 — https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html
FIDO Alliance Passkeys — https://fidoalliance.org/passkeys/
IANA COSE Algorithms — https://www.iana.org/assignments/cose/cose.xhtml

OS / プラットフォーム。

Apple Passwords アプリ — https://www.apple.com/legal/privacy/data/en/passwords/
Apple Developer "Supporting passkeys" — https://developer.apple.com/documentation/authenticationservices/public-private-key-authentication
Android Credential Manager — https://developer.android.com/identity/sign-in/credential-manager
Windows Hello WebAuthn — https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/passwordless-strategy

ライブラリ。

SimpleWebAuthn — https://simplewebauthn.dev/
@simplewebauthn/server — https://github.com/MasterKale/SimpleWebAuthn
py-webauthn — https://github.com/duo-labs/py_webauthn
webauthn-rs — https://github.com/kanidm/webauthn-rs

SaaS / オープンソース認証。

Auth0 Passkeys — https://auth0.com/docs/authenticate/database-connections/passkeys
Okta FastPass — https://www.okta.com/products/fastpass/
Clerk — https://clerk.com/docs/authentication/configuration/passkeys
Stytch — https://stytch.com/docs/passkeys
SuperTokens — https://supertokens.com/
Logto — https://logto.io/
Hanko — https://www.hanko.io/
Passage by 1Password — https://passage.id/

パスワードマネージャパスキー同期。

1Password Passkeys — https://blog.1password.com/passkeys/
Bitwarden Passkeys — https://bitwarden.com/passwordless-passkeys/
Dashlane Passkeys — https://www.dashlane.com/passkeys

韓国 / 日本事例。

Yahoo!Japan WebAuthn 事例(Internet Week)— https://yahoo-id.github.io/
Naver Passkey — https://nid.naver.com/
LINE Passkey — https://developers.line.biz/
docomo d アカウント FIDO — https://www.docomo.ne.jp/

政府 / コンプライアンス。

Login.gov passkeys — https://www.login.gov/help/
NIST SP 800-63B — https://pages.nist.gov/800-63-3/sp800-63b.html
FedRAMP ポリシーガイド — https://www.fedramp.gov/