LabHub

ブログ

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

2026-05-15 · 27 分で読めます · #passkey#webauthn#fido2#passwordless#auth0#clerk#stytch#logto#supertokens#hanko#passage#authentication#deep-dive#japanese

한국어English日本語

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

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

本記事は 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・金融認証書陣営がまだ強いが、一部の大手テックが動いた。

残る課題もある。

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

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

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

図にするとこうなる。

[ユーザー ブラウザ/アプリ]
   |  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 / UVUser Present / User Verified ビット
signCountcounter が単調増加しているか(クローン検出)
署名検証clientDataJSON と authenticatorData を合わせて公開鍵で検証

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

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

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

ポイント。

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

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

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

注意点として 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)

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

WebAuthn 標準との違い。

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

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

1Password。

Bitwarden。

Dashlane。

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,
})

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 サーバーへ送付 → ログイン成功

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

なぜよいか。

弱点。

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

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

Auth0(Okta 子会社)。

Okta Workforce Identity Cloud。

Microsoft Entra ID(旧 Azure AD)。

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

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

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

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

Clerk。

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

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

Stytch。

Passage(1Password 買収)。

3 社の共通点。

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

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

SuperTokens。

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

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

Logto。

Hanko。

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

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

弱点。

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

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

Naver。

Kakao。

Toss。

公共・金融。

示唆。

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

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

docomo ID。

au ID(KDDI)。

SoftBank ID / Y!mobile。

Yahoo!Japan。

LINE。

マイナンバーカード。

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

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

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

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

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

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

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

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

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

メトリクス。

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

第 14 章 · 参考 / References

標準 / 仕様。

OS / プラットフォーム。

ライブラリ。

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

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

韓国 / 日本事例。

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

コメント

まだコメントはありません。

ログインするとコメントできます