Login v2 — passkey fails on first attempt (WEBAU-3M9si / COMMAND-Ioqu5), retry works — fix PR open
🌟Contribution✅Solved🪲Bugs
I've run into a reproducible issue on the hosted Login v2 where authenticating with a passkey fails on the first attempt and only goes through on a retry. In the browser the user gets "An error occurred during passkey verification" (the i18n key is passkey.verify.errors.verificationFailed), while the API logs a WARN "Session without WebAuthN challenge (COMMAND-Ioqu5)" immediately followed by an ERROR "Error on validate login credentials (WEBAU-3M9si)". It's intermittent, and noticeably easier to reproduce in Firefox or over higher latency.
I'm on Zitadel v4.15.0 self-hosted with a single Login v2 replica, and the RP-ID / external domain config all checks out, so this isn't a misconfiguration on my side. It also isn't version-specific: per #12495 it reproduces from v4.13.1 through v4.16.1, so bumping the version doesn't help.
Digging into it, the passkey page starts a WebAuthn ceremony automatically on mount, but the submit button stays clickable while that navigator.credentials.get() prompt is still open. A second trigger — an impatient click, or an RSC remount of the page — mints a second challenge that overwrites the first one on the session, so when the assertion finally arrives it's checked against a challenge that's already been replaced. That produces WEBAU-3M9si, which login-v2's own session fallback then surfaces as COMMAND-Ioqu5.
I've opened a fix for it in #12509 (closes #12495). It consolidates the flow into a single ceremony that keeps the submit button disabled until it settles, and uses one AbortController to supersede or cancel any in-flight get() and to ignore late results from an aborted one, with unit tests covering the behaviour.
The PR is ready for review, but since I'm a first-time contributor the CI is gated on maintainer approval and hasn't run yet, so if a maintainer could approve the workflow run and take a look when there's time, I'd really appreciate it. Thanks!
I'm on Zitadel v4.15.0 self-hosted with a single Login v2 replica, and the RP-ID / external domain config all checks out, so this isn't a misconfiguration on my side. It also isn't version-specific: per #12495 it reproduces from v4.13.1 through v4.16.1, so bumping the version doesn't help.
Digging into it, the passkey page starts a WebAuthn ceremony automatically on mount, but the submit button stays clickable while that navigator.credentials.get() prompt is still open. A second trigger — an impatient click, or an RSC remount of the page — mints a second challenge that overwrites the first one on the session, so when the assertion finally arrives it's checked against a challenge that's already been replaced. That produces WEBAU-3M9si, which login-v2's own session fallback then surfaces as COMMAND-Ioqu5.
I've opened a fix for it in #12509 (closes #12495). It consolidates the flow into a single ceremony that keeps the submit button disabled until it settles, and uses one AbortController to supersede or cancel any in-flight get() and to ignore late results from an aborted one, with unit tests covering the behaviour.
The PR is ready for review, but since I'm a first-time contributor the CI is gated on maintainer approval and hasn't run yet, so if a maintainer could approve the workflow run and take a look when there's time, I'd really appreciate it. Thanks!
