필사 모드: Passkeys and WebAuthn in 2026 — FIDO2, Auth0, Clerk, Stytch, Logto, SuperTokens, Hanko Deep Dive

Prologue — In 2026 the death of passwords actually started

When Apple, Google, and Microsoft jointly announced "we will adopt passkeys" back in May 2022, most people shrugged. "Here we go again — OAuth 2.0 took ten years to land" was the typical reaction. As of May 2026, however, the change is visible.

- The U.S. government login portal **Login.gov** added passkeys as a primary authentication option.

- The **Apple Passwords app** became a first-class citizen in iOS 18 / macOS Sequoia. It is the successor to iCloud Keychain but with a completely different UX.

- The **Android 15 Credential Manager** unified passkeys and passwords behind a single API.

- **1Password, Bitwarden, and Dashlane** all formally support cross-platform passkey sync.

- **WebAuthn Level 3** became a W3C Recommendation in September 2024. Conditional UI (a passkey picker that behaves like autofill) is part of the standard.

- **Hybrid transport (caBLE then CTAP 2.2)** stabilized the scenario of using a phone as an authenticator on desktops.

This post maps the passkey and WebAuthn ecosystem as of May 2026. We cover user, developer, and operator perspectives. We start with the standard stack, then platform UX (iOS and Android), then auth SaaS (Auth0, Clerk, Stytch, SuperTokens, Logto, Hanko, Passage), then Korean and Japanese operators, and finally how to gradually migrate from existing password systems.

Code samples deliberately use **@simplewebauthn/server** and **@simplewebauthn/browser** as the reference. That library is effectively the Node standard, and other SaaS expose APIs that look the same internally.

1. End of passwords in 2026 — how far have we come

Four years after the 2022 announcement, here are the five most meaningful changes.

**First, OS-level first-class citizenship.** Through iOS 17 passkeys lived under iCloud Keychain. In iOS 18 the Passwords app split out, sending a clear signal to users that "passkeys are better than passwords." Android 15 did the same with the Credential Manager API.

**Second, cross-platform sync.** Passkeys had a weakness: "you get locked into one ecosystem." Between 2024 and 2025 1Password, Bitwarden, and Dashlane all added passkey sync, which fixed that problem. A passkey created in iCloud can now be used on Windows through 1Password.

**Third, Conditional UI.** The most important feature in WebAuthn Level 3. When the user focuses the username field of a login form, passkey candidates show up like autofill. The user does not need to press a separate button. This UX reframes passkeys as "the autofill you already know."

**Fourth, Hybrid transport.** The desktop-uses-phone-passkey scenario. Show a QR code, scan with the phone, verify proximity over BLE. This was formalized in CTAP 2.2 specification.

**Fifth, government and finance adoption.** Login.gov started accepting passkeys, and the U.S. SSA is following. Japan kicked off a pilot in 2025 linking My Number Card to passkeys. Korea still has strong incumbents (PASS, financial certificates), but some big tech moved.

Open problems remain.

- **Account recovery**: how do you recover when all devices are lost. No standard yet; vendors differ.

- **User education**: the cost of explaining "what is a passkey" is still high.

- **Legacy compatibility**: password managers, SMS OTP, and 2FA apps coexist, confusing users.

- **B2B / SCIM**: managing passkey policy from the IdP level for the enterprise is just beginning.

We return to these problems later in this post.

2. WebAuthn / FIDO2 / CTAP — sorting out the standard stack

The terminology is easy to confuse. One-line summary.

- **FIDO2** = umbrella name for WebAuthn (W3C) + CTAP (FIDO Alliance).

- **WebAuthn** = JavaScript API between browser and server. `navigator.credentials.create()` / `.get()`.

- **CTAP** = wire protocol between browser and external authenticator. CTAP 1 (U2F), CTAP 2.0, 2.1, 2.2.

- **Passkey** = marketing name for a WebAuthn credential that is "synced and discoverable." Technically a resident key plus multi-device.

Pictured.

[user browser/app]

| 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

[authenticator] (Secure Enclave / TPM / Titan / YubiKey / iPhone / Android phone)

The core of the WebAuthn API is two functions.

// 1) Registration — create a new passkey

const credential = await navigator.credentials.create({

publicKey: {

challenge: serverChallenge, // random nonce from server

rp: { id: 'example.com', name: 'Example' },

user: {

id: new Uint8Array(userIdBytes), // server-side 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', // most consumer services accept none

}

})

// 2) Authentication — log in with an existing passkey

const assertion = await navigator.credentials.get({

publicKey: {

challenge: serverChallenge,

rpId: 'example.com',

userVerification: 'preferred',

// empty allowCredentials triggers the discoverable-credential picker

allowCredentials: [],

},

mediation: 'conditional', // enables Conditional UI

})

What the server needs to verify.

| Verification | Meaning |

| --- | --- |

| Challenge match | response includes the server-issued challenge |

| Origin match | clientDataJSON.origin equals the RP origin |

| rpIdHash match | authenticatorData.rpIdHash equals SHA-256 of the RP id |

| flags.UP / UV | User Present / User Verified bits |

| signCount | counter increases monotonically (clone detection) |

| Signature | verify clientDataJSON plus authenticatorData with the public key |

Implementing this yourself will fail 100 percent of the time. So almost everyone uses a library. We see it next.

3. iOS 18 + macOS Sequoia Passwords app — Apple's move

The quietest yet most meaningful change in iOS 18 (September 2024) was the **Passwords app**. iCloud Keychain used to be buried in Settings, and breaking it out as a standalone app finally made it look like a password manager.

Highlights.

- **Standalone app**: accessible from Spotlight, Dock, home screen. Synced across macOS, iOS, iPadOS, visionOS, and Windows (iCloud for Windows).

- **Category split**: Passwords / Passkeys / Wi-Fi / Verification Codes (TOTP) / Security recommendations. Passkeys is its own category.

- **Shared groups**: share passkeys with family or team. Follow-on to password sharing.

- **Verification Codes integration**: the same app autofills 6-digit OTPs. Separate authenticator apps get weaker.

- **Security recommendations**: weak passwords, reuse, and breach-list matches.

User flow.

1. Sign up at example.com in Safari

2. While filling the form, "Passwords" offers to save automatically

3. User: one Face ID

4. Passkey registered, stored in iCloud Keychain

5. Other devices (Mac, iPad) log in to the same account immediately

What developers should know.

- **Associated Domains**: a native iOS app must declare the `webcredentials` domain in `apple-app-site-association`.

- **AutoFill integration**: ASAuthorizationPlatformPublicKeyCredentialProvider for form autofill. SwiftUI uses `.textContentType(.username)` plus `.authorizationController()`.

- **Same Sign-in Account**: passkeys auto-sync to every device signed in with the same Apple ID. Same E2EE model as iCloud Keychain.

- **Shared groups**: from iOS 18 `ASCredentialIdentityStore` exposes group-shared passkeys.

A note on **attestation**: there is essentially none. Apple Anonymous Attestation exists, but most consumer services should accept `attestation: 'none'`. Strong attestation is needed only by enterprise, government, and financial deployments.

4. Android 15 Credential Manager — passkeys and passwords unified

Google built **Credential Manager** to clean up the fragmentation of Android auth APIs. It went beta in Android 14 and became GA in Android 15. The core idea is "passwords, passkeys, and federated logins (Google Sign-In) behind one API."

// Android Credential Manager — registration

val request = CreatePublicKeyCredentialRequest(

requestJson = serverChallengeJson,

preferImmediatelyAvailableCredentials = true,

)

val credential = CredentialManager.create(context)

.createCredential(activity, request)

// Authentication

val getRequest = GetCredentialRequest(

credentialOptions = listOf(

GetPublicKeyCredentialOption(serverRequestJson),

GetPasswordOption(), // existing passwords are exposed too

),

)

val response = CredentialManager.create(context)

.getCredential(activity, getRequest)

Wins.

- **Single entry point**: the user logs in without knowing whether it is a passkey or password.

- **Third-party providers**: 1Password, Bitwarden, and Dashlane appear in the same OS-level dialog.

- **Digital Asset Links**: standard for binding web domain and app. Declaring `delegate_permission/common.get_login_creds` in `assetlinks.json` lets the same passkey work in both the app and the web.

Differences from the WebAuthn standard.

- The Android `requestJson` follows the W3C `PublicKeyCredential.toJSON()` JSON-encoding standard verbatim. So the server can reuse the same WebAuthn library.

- The equivalent of `mediation: 'conditional'` is `preferImmediatelyAvailableCredentials = true`.

5. 1Password / Bitwarden / Dashlane — cross-platform passkey sync

OS-side sync (Apple Keychain, Google Password Manager) only works within one ecosystem. So the role of **third-party password managers** grew. Between 2024 and 2025 all three major ones added passkey sync.

**1Password.**

- Passkey create and store support since June 2023, sync stabilized in 2024.

- Browser extension on Windows, macOS, Linux, iOS, Android, web. Most attractive to Linux users who cannot use Apple Keychain passkeys.

- Acquired Passage (passage.id) in 2024. Strategy to pull users into its own auth SaaS.

- Watchtower recommends sites that support passkeys.

**Bitwarden.**

- Open source (OSS). Self-hostable (vaultwarden is unofficial but popular).

- Browser extension passkey storage started November 2023. Mobile followed in 2024.

- Strong selling point: even the free plan offers passkey features without limits.

**Dashlane.**

- Was first to announce consumer passkeys in September 2022. Took the marketing lead.

- Strengthened the enterprise lineup from 2024 with SCIM integration and SSO routing.

- Differentiates via Confidential SSO (client-side E2EE).

What they share is **a precise implementation of WebAuthn Conditional UI**. Browser extensions do not fight the OS credential provider; they let the user pick.

6. WebAuthn Level 3 (2024.9 W3C Recommendation) — Conditional UI and Auto-fill

WebAuthn Level 2 became a W3C Recommendation in 2021, and Level 3 reached the final recommendation in September 2024. Five key changes.

**1. Conditional UI (Auto-fill).**

// Call early at page load. mediation: 'conditional' is the key.

const cred = await navigator.credentials.get({

publicKey: {

challenge: serverChallenge,

rpId: 'example.com',

allowCredentials: [], // must be empty for discoverable lookup

},

mediation: 'conditional',

signal: abortController.signal,

})

- When the user focuses the username input (`autocomplete="username webauthn"`), passkey candidates show up like autofill.

- The user does not need to press a separate "Sign in with passkey" button.

- iOS Safari, Chrome, Edge, and Firefox all support it.

**2. JSON encoding.** `PublicKeyCredential.toJSON()` is standardized. The server receives JSON instead of handling ArrayBuffers directly.

**3. PRF extension.** Pseudo-Random Function extension. Lets you derive a deterministic secret (for example an E2EE key) from a passkey. 1Password demoed a PoC of unlocking vaults this way.

**4. largeBlob stabilization.** Store small data (for example a user-defined label) alongside the authenticator.

**5. Direct attestation formats.** Apple and Google brought additional attestation formats into the standard.

7. Hybrid transport (caBLE then CTAP 2.2) — phone-as-authenticator

"I am logging into a website on my laptop but the passkey is on my phone" is the most common pain point. From 2022 it was experimented with under the name **caBLE (Cloud Assisted Bluetooth Low Energy)**, and in 2024 it landed in **CTAP 2.2** under the official name **Hybrid transport**.

Flow.

1. Browser on the PC shows a QR code

2. User scans with the phone camera

3. Phone performs a handshake through the cloud (Apple/Google push infra)

4. Phone and PC confirm proximity via BLE signaling

5. User does Face ID/Touch ID/fingerprint on the phone

6. Phone produces a signature and relays it via the cloud to the PC

7. PC forwards the signature to the RP server — login succeeds

The security model of this flow is interesting.

- **BLE proximity**: relying on the cloud alone is not enough, so BLE confirms physical proximity.

- **End-to-end encryption**: the QR code carries an ephemeral ECDH public key, and the phone and PC build a direct E2EE channel from it. Apple/Google clouds see only encrypted traffic.

- **One-shot**: it works exactly once. No permanent pairing.

Why this is good.

- iPhone passkeys can be used on Windows PCs.

- Android phone passkeys can be used on Macs.

- It is safe to use on someone else's PC (for example an internet cafe).

Downsides.

- BLE must be on. Laptops with corporate policies that disable BLE cannot do it.

- It takes 30 to 60 seconds per attempt. Slower than Conditional UI.

8. Auth0 / Okta — the enterprise camp

When large companies adopt passkeys, Auth0/Okta is the first thing that comes to mind. Both formally support passkeys.

**Auth0 (Okta subsidiary).**

- Toggle "Passkey" on Database connections to enable passkey login. Integrated with Universal Login.

- Combinable with "Progressive profiling" workflows. First sign-up by passkey, additional information collected later.

- Pricing: B2C is MAU-based, B2B is seat-based. Passkeys themselves do not incur extra fees.

**Okta Workforce Identity Cloud.**

- Workforce IdP. SCIM, SAML, OIDC, MFA, policy engine.

- In 2024 Okta FastPass integrated passkeys. Passkeys registered on user devices are policy-managed at the IdP level.

- Yubikey, Windows Hello, and Touch ID are supported simultaneously.

**Microsoft Entra ID (formerly Azure AD).**

- Same category but Microsoft-ecosystem bundle. Entra supports passkeys and integrates with the Authenticator app.

- Glues smoothly with Hello for Business on company-managed Windows devices.

What this camp shares is **governance**. Passkey policies are managed by IT, not by the user.

- Which attestation to accept (for example only FIPS-certified keys).

- Which devices may register passkeys.

- How to reissue passkeys when lost.

Consumer SaaS rarely addresses these.

9. Clerk / Stytch / Passage — developer-friendly SaaS

In the startup and developer camp a different class of SaaS is popular.

**Clerk.**

- Founded in 2020. Optimized for the Next.js and React ecosystem. Components like `<SignIn />` and `<UserButton />` work out of the box.

- Passkeys officially supported since 2024. `clerkClient.users.createPasskey()` API and automatic UI.

- Multi-session, organizations, invitations, and other SaaS patterns work immediately.

- Pricing: MAU-based. 10K MAU free.

// Clerk — Next.js example (concept)

export default function Page() {

return <SignIn signInUrl="/sign-in" />

// passkeys, email, and OAuth are exposed automatically

}

**Stytch.**

- Founded in 2020. Founders from Plaid. API-first.

- B2C combines Frontend SDK plus Backend SDK. B2B (Stytch B2B) adds SCIM and SSO routing separately.

- Passkeys formally supported since 2023. Full stack including M2M tokens.

- Focused on "Passwordless" scenarios (Magic Link plus Passkey).

**Passage (acquired by 1Password).**

- Founded in 2022. Started as a passkey-only SaaS.

- Acquired by 1Password in January 2024. Repositioned for the passkey-plus-1Password vault integration scenario.

- Generous free plan (10K MAU free).

- Well-stocked React / JavaScript / Next.js SDKs.

What the three have in common.

- **Conditional UI on by default**: making a username field automatically activates autofill.

- **Account recovery flow**: fallback to magic links or OTP when passkeys are lost.

- **Drop-in UI vs Headless**: both modes are supported. Headless if you want full design control.

10. Logto / SuperTokens / Hanko — open source options

Teams that need self-hosting, that face GDPR or data sovereignty issues, or that want to control cost have open source options.

**SuperTokens.**

- Founded in 2020. Y Combinator. MIT license.

- Core service plus Node/Python/Go backend SDKs plus React or plain JS frontend SDK.

- "Recipe" concept: compose passwordless, password, third-party, and MFA.

- Passkeys formally supported since 2024. Self-host possible.

- Pricing: OSS is free. Managed (SuperTokens Cloud) is MAU-based.

// SuperTokens — passkey recipe (concept)

SuperTokens.init({

recipeList: [

Passkey.init({

// RP info, challenge generation, and verification handled by the library

}),

Session.init(),

],

})

**Logto.**

- Founded in 2022. Strong in Chinese and Asian markets. Apache 2.0.

- Specialized in Customer Identity (CIAM). Multilingual, SSO, social login.

- Self-host and Logto Cloud are both available.

- Passkeys formally supported in 2024. WebAuthn Level 3 compatible.

**Hanko.**

- Founded in 2022. German company. Emphasizes EU data sovereignty.

- AGPL plus commercial dual-license. Hanko Cloud.

- "Passkey-first" is the slogan. Enforces passkey as default with password as fallback.

- The drop-in UI ("hanko-elements") is clean.

<!-- Hanko — drop-in component (concept) -->

register({ shadow: true })

Shared strengths of the open source camp.

- **Self-host possible**: data stays on your infrastructure.

- **Lock-in avoidance**: less risk from pricing-policy changes.

- **Auditable**: read and verify the code itself.

Weaknesses.

- **Operational burden**: you manage the DB, session storage, and key rotation.

- **UX polish gap**: not always as smooth as managed SaaS.

- **Compliance certifications**: SOC 2 and ISO 27001 apply to your own infrastructure.

11. Korea — Naver / Kakao / Toss passkey adoption

Korea is slower than the global average at adopting passkeys. Two reasons. First, the **Financial Certificate / Joint Certificate / PASS** ecosystem is strong. Second, finance still relies heavily on **ARS and OTP**.

**Naver.**

- "Naver Passkey" went beta in October 2024. Issued from the Naver app, used on the web for login.

- Exposed as the default option to some users in 2025.

- Used as the entry point to the Naver Series (Whale, WORKS, Naver Pay).

**Kakao.**

- Working to merge KakaoTalk authentication and Kakao Account authentication. Passkeys went beta in early 2025.

- Security-sensitive services (KakaoBank, Kakao Pay) still use PIN plus biometrics.

- Only Kakao i Cloud users get passkey sync.

**Toss.**

- Has its own Toss Certificate ecosystem, so it is cautious about passkeys.

- Started passkey PoC late 2025. Formal adoption expected in the second half of 2026.

- Passkeys for merchant-owner dashboards landed first in Toss Payments.

**Public sector and finance.**

- **PASS (the three telcos)** is keeping its own ecosystem. Direction is to use FIDO inside PASS rather than passkeys directly.

- **Financial Certificate (2020 private certification introduction)** runs on KFTC infrastructure. A different tech stack from passkeys but with a similar user experience.

- **Mobile ID Card (2024)** is DID-based. A different standard from passkeys but shares the same "shared key" flow.

**Implications.**

- Korea has a fragmented auth market. Passkeys need more time to settle.

- For B2C services it is realistic to ship passkeys as "an option for Korean users."

- For B2B SaaS entering Korea it is safe to expose SAML/OIDC plus passkeys side by side.

12. Japan — docomo / au / SoftBank ID, Yahoo!Japan

Japan is a bit more standardized in auth than Korea. Telco IDs, My Number, and the LINE/Yahoo! strategy interlock.

**docomo ID.**

- Passkeys went beta in 2024. Integrated as part of d Account.

- Expanding into payment authentication for d Pay and d Card.

**au ID (KDDI).**

- Passkeys formally supported in late 2024. Used in au PAY payments.

**SoftBank ID / Y!mobile.**

- After LINE Yahoo merged, integration with Yahoo!Japan ID proceeded. Passkeys are one axis of that integration.

**Yahoo!Japan.**

- Pilot passkey adoption since 2022 — the earliest large case in Japan.

- Tens of millions of users had passkeys by 2024.

- Has the richest operational case studies and is cited as a reference within Japan.

**LINE.**

- LINE Login has had passkeys since 2023. Rolled out quickly in Japan, Thailand, and Taiwan.

- Applied to LINE Pay payment authentication.

**My Number Card.**

- Japan's national digital ID. Originally authenticated by card-plus-PIN on Mynaportal.

- Pilot since 2025 exposing My Number Card certificates in passkey form.

The Japanese characteristic is that **telcos and platforms are aggressive about passkey adoption**. The government is also pulling compatibility together through My Number Card.

13. Passkey migration strategy — how to adopt gradually

How do you slip passkeys into an existing password system. Five steps.

**Step 1: add passkey registration as an option.**

- Expose "register a passkey" inside "Security settings" after login.

- Existing password users register a passkey as an additional authentication method.

- A single user can register multiple passkeys (desktop, phone, iPad).

**Step 2: add Conditional UI to the login form.**

- Set `autocomplete="username webauthn"` on the username input.

- Call `navigator.credentials.get({ mediation: 'conditional' })` at page load.

- Password users are unaffected. Passkey users get candidates popping up like autofill.

**Step 3: make passkeys the default at sign-up.**

- Present "passkey instead of password" as the default to new users.

- Users must explicitly opt out to use a password.

- Fall back to an email magic link.

**Step 4: upsell existing password users.**

- On login, ask "Sign in faster next time with a passkey?"

- A/B test and monitor conversion. (Usually 20-40 percent uptake.)

- Suggest gently, do not force.

**Step 5: introduce passkey-only mode.**

- Let users opt in to "disable password."

- Within the limits of government and financial compliance.

**Account recovery — the most important part.**

- A user who lost all devices must still have a way back into the account.

- Email magic link, SMS OTP, recovery codes, identity verification.

- "Passkey equals more secure" is great, but "passkey equals unrecoverable" is a deal-breaker for adoption.

**Metrics.**

- Passkey registration rate (signed-up users who registered a passkey).

- Passkey login ratio (logins that used a passkey).

- Passkey auth success rate (successes per attempt).

- Passkey fallback rate (failed and fell back to password).

Track these four and gradually shrink the password share.

14. References

**Standards / specs.**

- 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 / platforms.**

- Apple Passwords app — 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

**Libraries.**

- 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 / OSS auth.**

- 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/

**Password manager passkey sync.**

- 1Password Passkeys — https://blog.1password.com/passkeys/

- Bitwarden Passkeys — https://bitwarden.com/passwordless-passkeys/

- Dashlane Passkeys — https://www.dashlane.com/passkeys

**Korea / Japan case studies.**

- Yahoo!Japan WebAuthn case (Internet Week) — https://yahoo-id.github.io/

- Naver Passkey — https://nid.naver.com/

- LINE Passkey — https://developers.line.biz/

- docomo d Account FIDO — https://www.docomo.ne.jp/

**Government / compliance.**

- Login.gov passkeys — https://www.login.gov/help/

- NIST SP 800-63B — https://pages.nist.gov/800-63-3/sp800-63b.html

- FedRAMP policy guide — https://www.fedramp.gov/