Repository navigation
Conversation
…actor
The Clerk backend can now offer passkey in a sign-in's (and session
reverification's) supported_second_factors when the instance allows
passkeys to satisfy the second factor and the user has a registered
passkey. This adds client support end to end:
- Types: passkey variants in SignInSecondFactor,
Prepare/AttemptSecondFactorParams, SessionVerificationSecondFactor,
and the session verify param unions.
- signIn.authenticateWithPasskey() detects needs_second_factor (and
needs_client_trust) and runs the prepare/attempt second-factor flow
against the in-progress sign-in instead of creating a new one; the
flow param is ignored there. attemptSecondFactor serializes the
WebAuthn credential like attemptFirstFactor. The future API gains
mfa.passkey().
- session.verifyWithPasskey({ level: 'second_factor' }) completes a
multi-factor step-up with a passkey.
- Prebuilt UI: passkey cards for the sign-in factor-two and
user-verification factor-two steps, offered via the existing
totp/phone-first ladder (passkey is only the starting factor when it
is the sole option), listed under "Use another method", and hidden
when WebAuthn is unsupported. Fixes the alternative-methods label
switch that threw on unknown second-factor strategies.
- New signIn.passkeyMfa / reverification.passkeyMfa localization keys.
Part of USER-3966
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 5d55d7a The changes in this PR will be included in the next version bump. This PR includes changesets to release 23 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 Walkthrough
🚥 Pre-merge checks | ✅ 5
Comment |
@clerk/astro
@clerk/backend
@clerk/chrome-extension
@clerk/clerk-js
@clerk/electron
@clerk/electron-passkeys
@clerk/eslint-plugin
@clerk/expo
@clerk/expo-biometrics
@clerk/expo-google-signin
@clerk/expo-native-components
@clerk/expo-passkeys
@clerk/express
@clerk/fastify
@clerk/hono
@clerk/localizations
@clerk/mosaic
@clerk/nextjs
@clerk/nuxt
@clerk/react
@clerk/react-router
@clerk/shared
@clerk/tanstack-react-start
@clerk/testing
@clerk/ui
@clerk/upgrade
@clerk/vue
commit: |
API Changes Report
Summary
@clerk/sharedCurrent version: 4.40.0 Subpath
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (1)
packages/ui/src/components/SignIn/__tests__/SignInFactorTwo.test.tsx (1)
407-424: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winTest may pass for the wrong reason — wrap in
mockWebAuthnto test priority ordering.Without
mockWebAuthn,isWebAuthnSupported()likely returns false in the test environment, so passkey is excluded from candidacy regardless of priority sorting against TOTP. This test currently can't distinguish "TOTP wins on priority" from "passkey is filtered out due to no WebAuthn support." Wrapping this inmockWebAuthn(() => { ... })(as done for the sibling tests below) would ensure the sorting/priority logic is actually exercised.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/ui/src/components/SignIn/__tests__/SignInFactorTwo.test.tsx` around lines 407 - 424, Update the Passkey test “is never the starting factor when another second factor is available” to wrap its fixture setup, render, and assertions in mockWebAuthn, matching the sibling tests below. Keep supportTotp and supportPasskey enabled so the test validates priority ordering rather than passkey being excluded by unsupported WebAuthn.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/clerk-js/src/core/resources/__tests__/SignIn.test.ts`:
- Around line 261-264: Restore direct static assignments in the passkey test
suites: update the authenticateWithPasskey and mfa.passkey cleanup to save the
original BaseResource._fetch and SignIn.clerk values before stubbing, then
reassign those originals in afterEach alongside vi.clearAllMocks() and
vi.unstubAllGlobals().
In `@packages/clerk-js/src/core/resources/Session.ts`:
- Around line 320-329: The verifyWithPasskey method silently treats invalid
levels as first-factor verification. Default level with nullish coalescing, then
explicitly validate that it is either 'first_factor' or 'second_factor' and
reject any other value before calling prepareFirstFactorVerification or
prepareSecondFactorVerification.
- Around line 320-329: Document the public verifyWithPasskey API with JSDoc
directly above the verifyWithPasskey method in Session, describing the
params.level options and default, the returned SessionVerificationResource, and
possible error behavior; flag the contract change for Docs-team review or
accompanying generated documentation updates.
In `@packages/clerk-js/src/core/resources/SignIn.ts`:
- Around line 575-610: Add or update JSDoc for the public
authenticateWithPasskey method to document that needs_second_factor and
needs_client_trust sign-ins reuse the in-progress sign-in via the second-factor
flow, and that the flow option is ignored in those states. Include the API
behavior change clearly and mark the documentation for Docs-team review.
In `@packages/ui/src/components/UserVerification/UVFactorTwoPasskeyCard.tsx`:
- Around line 32-41: Update handlePasskeysAttempt to guard against concurrent
passkey attempts: set the card’s loading state before calling verifyWithPasskey,
clear it in a finally handler regardless of success or failure, and disable the
passkey button while loading so additional clicks cannot abort the in-flight
ceremony.
---
Nitpick comments:
In `@packages/ui/src/components/SignIn/__tests__/SignInFactorTwo.test.tsx`:
- Around line 407-424: Update the Passkey test “is never the starting factor
when another second factor is available” to wrap its fixture setup, render, and
assertions in mockWebAuthn, matching the sibling tests below. Keep supportTotp
and supportPasskey enabled so the test validates priority ordering rather than
passkey being excluded by unsupported WebAuthn.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Repository UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: c030f53b-d9cd-46b4-8a0f-e7f81cb887a2
📒 Files selected for processing (73)
.changeset/passkey-second-factor.mdpackages/clerk-js/src/core/resources/Session.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/resources/__tests__/Session.test.tspackages/clerk-js/src/core/resources/__tests__/SignIn.test.tspackages/localizations/src/ar-SA.tspackages/localizations/src/be-BY.tspackages/localizations/src/bg-BG.tspackages/localizations/src/bn-IN.tspackages/localizations/src/ca-ES.tspackages/localizations/src/cs-CZ.tspackages/localizations/src/da-DK.tspackages/localizations/src/de-DE.tspackages/localizations/src/el-GR.tspackages/localizations/src/en-GB.tspackages/localizations/src/en-US.tspackages/localizations/src/es-CR.tspackages/localizations/src/es-ES.tspackages/localizations/src/es-MX.tspackages/localizations/src/es-UY.tspackages/localizations/src/fa-IR.tspackages/localizations/src/fi-FI.tspackages/localizations/src/fr-FR.tspackages/localizations/src/he-IL.tspackages/localizations/src/hi-IN.tspackages/localizations/src/hr-HR.tspackages/localizations/src/hu-HU.tspackages/localizations/src/id-ID.tspackages/localizations/src/is-IS.tspackages/localizations/src/it-IT.tspackages/localizations/src/ja-JP.tspackages/localizations/src/kk-KZ.tspackages/localizations/src/ko-KR.tspackages/localizations/src/mn-MN.tspackages/localizations/src/ms-MY.tspackages/localizations/src/nb-NO.tspackages/localizations/src/nl-BE.tspackages/localizations/src/nl-NL.tspackages/localizations/src/pl-PL.tspackages/localizations/src/pt-BR.tspackages/localizations/src/pt-PT.tspackages/localizations/src/ro-RO.tspackages/localizations/src/ru-RU.tspackages/localizations/src/sk-SK.tspackages/localizations/src/sr-RS.tspackages/localizations/src/sv-SE.tspackages/localizations/src/ta-IN.tspackages/localizations/src/te-IN.tspackages/localizations/src/th-TH.tspackages/localizations/src/tr-TR.tspackages/localizations/src/uk-UA.tspackages/localizations/src/vi-VN.tspackages/localizations/src/zh-CN.tspackages/localizations/src/zh-TW.tspackages/shared/src/internal/clerk-js/errors.tspackages/shared/src/types/localization.tspackages/shared/src/types/session.tspackages/shared/src/types/sessionVerification.tspackages/shared/src/types/signInCommon.tspackages/shared/src/types/signInFuture.tspackages/ui/src/components/SignIn/SignInClientTrust.tsxpackages/ui/src/components/SignIn/SignInFactorTwo.tsxpackages/ui/src/components/SignIn/SignInFactorTwoAlternativeMethods.tsxpackages/ui/src/components/SignIn/SignInFactorTwoPasskeyCard.tsxpackages/ui/src/components/SignIn/__tests__/SignInFactorTwo.test.tsxpackages/ui/src/components/SignIn/shared.tspackages/ui/src/components/SignIn/utils.tspackages/ui/src/components/UserVerification/UVFactorTwoAlternativeMethods.tsxpackages/ui/src/components/UserVerification/UVFactorTwoPasskeyCard.tsxpackages/ui/src/components/UserVerification/UserVerificationFactorTwo.tsxpackages/ui/src/components/UserVerification/__tests__/UVFactorTwo.test.tsxpackages/ui/src/test/fixture-helpers.tspackages/ui/src/utils/factorSorting.ts
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/shared/src/internal/clerk-js/errors.ts (1)
105-112: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDocument the exported error helper.
The new exported function has an empty JSDoc block. Add accurate
@param,@returns,@throws, and@exampledocumentation describing the supported verification levels and caller-facing error. If this export is reference-facing, please also have the Docs team review the generated API content.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/shared/src/internal/clerk-js/errors.ts` around lines 105 - 112, Document the exported clerkInvalidVerificationLevel helper with complete JSDoc: describe functionName and level via `@param`, state the never return behavior via `@returns`, document the thrown caller-facing error via `@throws`, and add an `@example` showing an invalid level and the supported first_factor and second_factor values. Keep the documentation aligned with the existing error message and request Docs review for the generated API content if this export is reference-facing.Sources: Coding guidelines, Path instructions
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@packages/shared/src/internal/clerk-js/errors.ts`:
- Around line 105-112: Document the exported clerkInvalidVerificationLevel
helper with complete JSDoc: describe functionName and level via `@param`, state
the never return behavior via `@returns`, document the thrown caller-facing error
via `@throws`, and add an `@example` showing an invalid level and the supported
first_factor and second_factor values. Keep the documentation aligned with the
existing error message and request Docs review for the generated API content if
this export is reference-facing.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Repository UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 9bc817b9-9d9f-4562-931c-26016589d189
📒 Files selected for processing (9)
.changeset/passkey-second-factor.mdpackages/clerk-js/src/core/resources/Session.tspackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/resources/__tests__/Session.test.tspackages/clerk-js/src/core/resources/__tests__/SignIn.test.tspackages/react/src/stateProxy.tspackages/shared/src/internal/clerk-js/errors.tspackages/shared/src/types/session.tspackages/ui/src/components/UserVerification/UVFactorTwoPasskeyCard.tsx
🚧 Files skipped from review as they are similar to previous changes (7)
- .changeset/passkey-second-factor.md
- packages/clerk-js/src/core/resources/tests/Session.test.ts
- packages/ui/src/components/UserVerification/UVFactorTwoPasskeyCard.tsx
- packages/clerk-js/src/core/resources/tests/SignIn.test.ts
- packages/shared/src/types/session.ts
- packages/clerk-js/src/core/resources/Session.ts
- packages/clerk-js/src/core/resources/SignIn.ts
If the environment variable on the backend is unset, the backend will not advertise passkeys for second factor. The javascript code, when on a new clerk js version that does support passkeys as second factor, was treating that as an error. Instead just fail gracefully, clients shouldn't be disrupted if the backend doesn't yet advertise support for something.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/clerk-js/src/core/resources/SignIn.ts (1)
594-619: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDuplicate second-factor passkey ceremony logic between
authenticateWithPasskeyandverifyMFAPasskey.Both blocks implement the same sequence (prepare second factor with
strategy: 'passkey'→ read/parse nonce → convert to public-key options → fetch credential → submit attempt), but diverge in error handling (clerkMissingWebAuthnPublicKeyOptions/rawthrow errorhere vs.ClerkRuntimeError/ClerkWebAuthnErrorthere). Extracting a shared private helper would prevent the two paths from drifting further as passkey second-factor logic evolves.Also applies to: 1563-1610
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/clerk-js/src/core/resources/SignIn.ts` around lines 594 - 619, Extract the duplicated second-factor passkey ceremony from authenticateWithPasskey and verifyMFAPasskey into a shared private helper on SignIn. Have both callers use the helper, preserving the existing prepareSecondFactor, nonce parsing, public-key option conversion, credential retrieval, and attemptSecondFactor flow while standardizing their error handling through the shared implementation.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@packages/clerk-js/src/core/resources/SignIn.ts`:
- Around line 594-619: Extract the duplicated second-factor passkey ceremony
from authenticateWithPasskey and verifyMFAPasskey into a shared private helper
on SignIn. Have both callers use the helper, preserving the existing
prepareSecondFactor, nonce parsing, public-key option conversion, credential
retrieval, and attemptSecondFactor flow while standardizing their error handling
through the shared implementation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Repository UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 37a94a0a-db64-4faf-8786-49a7017aba5d
📒 Files selected for processing (4)
.changeset/passkey-second-factor.mdpackages/clerk-js/src/core/resources/SignIn.tspackages/clerk-js/src/core/resources/__tests__/SignIn.test.tspackages/shared/src/internal/clerk-js/errors.ts
💤 Files with no reviewable changes (1)
- packages/shared/src/internal/clerk-js/errors.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- .changeset/passkey-second-factor.md
| return localizationKeys('signIn.alternativeMethods.blockButton__passkey'); | ||
| default: | ||
| ((_: never) => _)(factor); | ||
| throw new Error('Invalid sign in strategy'); |
There was a problem hiding this comment.
There seems to be a case where this can throw and crash after this PR:
- FAPI on
2026-08-20 - Latest
clerk-js - Pinned
uito older version PasskeySettings.SatisfiesSecondFactortrue- The user has a verified passkey and didn't use it as the first factor
- Click on "Use another method"
When this happens, the older UI version wont recognize the factor and hit this throw.
I think we need to gate on both FAPI and UI version?
~ Found by 🤖, written up by 👨
There was a problem hiding this comment.
This is a good point, thanks for pointing out the clerk-js/ui pinning split possibility. It looks like we've never had to (or never bothered to) anticipate this before, so implementing it, while of course possible, is a bit more of an involved change than I expected. I'll take a look.
There was a problem hiding this comment.
I think when we have hit this in the past we have usually been able to work around it by providing a backwards compatible API without looking specifically at the uiVersion. The ui package is still somewhat new so I don't think we've run into this too many times either (I just remember a React Query mismatch really).
There was a problem hiding this comment.
I commented on the wrong comment, I implemented a guard here b104169. It's a bit complex since we haven't done exactly this before, but this was the simplest approach I could think of which is also safe for different loading orders (I believe).
There was a problem hiding this comment.
Annoying as it is to have to handle, I think that seems like a reasonable approach. I'm trying to think through how we best handle this and I'm a bit stumped tbh. Do you have any thoughts here @nikosdouvlis?
Context is, a component in UI isn't handling unknown factors well (throwing) and we want to introduce a new one without breaking people who have pinned old UI versions.
Daniels approach tackles it by introducing a __internal_capabilities field on ui and rewiring things in clerk-js a bit to always be able to get a hold of that even when ui was provided and not hotloaded.
We should avoid relying on __internal_capabilities and instead build UI in a defensive enough way that it can handle additive features, so if we go this route I'd see it as an escape hatch rather than something to encourage.
There was a problem hiding this comment.
I was pondering this again today and I realized something that's tricky here. We are now changing clerk-js behavior regardless of who is using it depending on which UI version is loaded. So if you pin UI and also use custom flows, your custom flows are now surprisingly affected by the UI pin.
Also, say you aren't loading UI at all? Then there's no way to flag the capability and your custom flow would never get this behavior.
I don't think that matters too much for this specific case, I'm only bringing it up since we are establishing a new pattern here.
Because of how UI is currently built I only really see two approaches here, either something like this, or just accept this as a latent bug in UI. The second route would be clearly better if we weren't hotloading clerk-js, but since that means we are the ones triggering the bug it's trickier.
Sorry for the delay and back and forth here, it's just that you happen to be the first one to run into this. I'll try to get some more eyes on it.
|
|
||
| // This is the currently supported version of the Frontend API | ||
| export const SUPPORTED_FAPI_VERSION = '2026-05-12'; | ||
| export const SUPPORTED_FAPI_VERSION = '2026-08-20'; |
There was a problem hiding this comment.
This also means that C1s using custom flows without a pinned clerk-js version will get the new supportedSecondFactors.
In theory, someone could be doing the same thing as us and have an exhaustive check, or could be mapping over all factors and not just known ones they handle in their app, but I think that's unlikely.
If building custom flows, I think you should either pin clerk-js or be resilient to additive changes, so I don't see this as a problem but still wanted to mention it as something to be aware of.
There was a problem hiding this comment.
I think that this is a more general point of company policy/culture. For better or for worse we add to API responses fairly often even on old API versions and don't treat it as a potential breaking change, although it can be if custom flows are used (or if our SDK is unexpectedly brittle). I think that we just have to accept this risk in cases like this; at least it's a new API version.
There was a problem hiding this comment.
Agreed! If this was a new case you had to handle in your custom flows that would be different.
Still good to think about every now and then though since there are trickier cases too. For example, if we add that "a separate '2FA required' flag" and now passkey might be the only supported 2FA, now custom flows might actually be in a dead end scenario if they don't handle it. Does that make it breaking even though it's in one sense purely additive?
There was a problem hiding this comment.
I added a guard here: b104169
There's definitely some complexity here and I'd appreciate your eyes on it. I tried to safely handle cases where we can't predict the order in which things will be loaded.
It's a bit of a bespoke implementation, but I couldn't come up with a reasonable entirely general approach.
…key-as-2fa-option # Conflicts: # packages/clerk-js/bundlewatch.config.json
Support guarding capabilities for `ui` when `ui` and `clerk-js` version may diverge. `clerk-js` should only include second factor passkey when it's included in the API response and then `ui` lists it as supported.
This reverts commit b104169. The backend now gates passkey in supported_second_factors for browser clients behind a per-instance opt-in, so clerk-js no longer needs to filter it based on the loaded UI's declared capabilities. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Prebuilt sign-in and reverification flows decided whether to preselect or offer a passkey with the plain browser check, ignoring `clerk.__internal_isWebAuthnSupported`. SDKs such as Electron set that override when passkeys can't work even though `PublicKeyCredential` exists, so those flows could open on a passkey card that always fails. Route the passkey checks for the starting first and second factor, and for the second-factor alternatives, through a new `useIsWebAuthnSupported` hook, matching what `SignInStart` already does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…key-as-2fa-option # Conflicts: # integration/tests/passkeys.test.ts # packages/clerk-js/src/core/resources/__tests__/SignIn.test.ts # packages/shared/src/types/session.ts
…udgets Passkey second-factor support in SignIn and Session pushes both bundles just over their gzipped budgets (82.02KB > 82KB, 322.45KB > 322.25KB). Raise each by 0.5KB. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Updates on this branch: |
…tor-two step Calling `signIn.mfa.passkey()` twice in quick succession sends two prepare_second_factor requests, so two passkey challenges are issued and the first ceremony's attempt fails against a replaced challenge. The prepare now coalesces, like the other MFA prepares. When passkey is the only second factor offered and the browser doesn't support WebAuthn, the prebuilt factor-two step shows a loading spinner that never resolves, leaving the user stuck. The starting factor now falls back to the passkey, so the passkey card renders and surfaces the unsupported error instead. Part of USER-3966 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The passkey second-factor suite fails on every run: enrolling the test user in TOTP is rejected with form_param_unknown (totp_secret), because the with-passkeys instance, now created from a Platform API config, does not enable the authenticator app. The suite also relies on passkeys being allowed to satisfy the second factor, which the config left to the instance default. Enable the authenticator app and set satisfies_second_factor explicitly. Part of USER-3966 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch was successfully deployed
3 participants
Users who have a passkey and sign in with a password (or OAuth, or a reset-password code) cannot use that passkey as their second factor: the SDK treats passkeys purely as a first-factor strategy, and the prebuilt UI's factor-two step throws on any second-factor strategy it doesn't know. The Clerk backend (clerk/clerk_go#20312) can now offer
passkeyin a sign-in's and a session reverification'ssupportedSecondFactorswhen the instance allows passkeys to satisfy the second factor and the user has a registered passkey. This adds client support end to end:SignInSecondFactor,Prepare/AttemptSecondFactorParams,SessionVerificationSecondFactor, and the session verify param unions.signIn.authenticateWithPasskey()detectsneeds_second_factor(andneeds_client_trust) and runs the prepare/attempt second-factor flow against the in-progress sign-in instead of creating a new one; theflowparam is ignored there.attemptSecondFactorserializes the WebAuthn credential likeattemptFirstFactor. The future API gainsmfa.passkey().session.verifyWithPasskey({ level: 'second_factor' })completes a multi-factor step-up with a passkey.signIn.passkeyMfa/reverification.passkeyMfalocalization keys.This relies on the FAPI API version bump to
2026-08-20(SUPPORTED_FAPI_VERSION): the backend only offers the passkey second factor to SDKs that request at least that version, so older clerk-js builds keep their current behavior with no changes.Part of USER-3966
Tested end to end against local clerk running clerk/clerk_go#20312 (real WebAuthn ceremonies via a Chromium virtual authenticator), comparing this branch with the published clerk-js 6.29.2 (
2026-05-12):authenticateWithPasskey()on the in-progress sign-in; first factor stayspassword/reset_password_email_code.supportedSecondFactorsisemail_code+passkey, andauthenticateWithPasskey()completes the sign-in.verifyWithPasskey({ level: 'second_factor' }),multi_factor(password → passkey; passkey as first factor alone also completes),first_factor, and the prebuilt reverification modal (starts on the passkey card,afterVerificationfires).<SignIn />: factor-two step starts on the passkey card, "Use another method" lists "Sign in with your passkey" and "Use your authenticator app", and the flow ends signed in.needs_second_factorwith no session; an authenticator without a matching credential rejects and creates no session.twoFactorEnabledstaysfalse; password sign-in completes once TOTP is removed).fvais[0,0]after TOTP, passkey-2FA, and passkey-first sign-ins.Checklist
pnpm testruns as expected.pnpm buildruns as expected.Type of change