Passkey login still prompts for OTP when Realm Passkeys is enabled (#52809) #52876

VivekanandChoudhary09 · 2026-09-17T07:02:42Z

VivekanandChoudhary09
Sep 17, 2026

Analysis: When Realm-setting > Login > Enable Passkeys is ON (regardless of the WebAuthn Passwordless Policy's own Enable-Passkeys toggle), a user who authenticates via passkey still gets prompted for OTP afterward. This only reproduces when the realm-level toggle is on — turning it off (even with the policy-level toggle on) avoids the bug entirely, which points to the realm-level flag driving a different code path in determining whether the login already satisfied MFA.

My current hypothesis: the conditional OTP authenticator in the browser flow (ConditionalUserConfiguredAuthenticator) does not check whether the user's just-completed authentication was already a passwordless/passkey credential. It goes straight into evaluating the sibling executions in the flow, so even after a passkey login, OTP is still treated as required.

Candidate fix: in ConditionalUserConfiguredAuthenticator.matchCondition(), check AuthenticatorUtil.getAuthnCredentials(context.getAuthenticationSession()).contains(WebAuthnCredentialModel.TYPE_PASSWORDLESS) first, and if true, return false (i.e. the OTP condition is not matched, so the OTP step is correctly skipped) before falling through to the existing matchConditionInFlow(...) logic.

I'd like to confirm this diagnosis with the core-authn team before submitting a PR, since this issue is still in Refinement. I have a candidate fix + integration test ready locally covering: passkey login → OTP condition correctly skipped, and password login → OTP condition correctly still required. Happy to share the diff here for early feedback, or wait for confirmation on root cause first.

lubineitor · 2026-09-17T18:48:56Z

lubineitor
Sep 17, 2026

The dependency on the realm-level “Enable Passkeys” setting is a useful clue, but I would be cautious about changing ConditionalUserConfiguredAuthenticator for this.

ConditionalUserConfiguredAuthenticator is intended to determine whether the user has configured the authenticators in the surrounding flow. Its current implementation evaluates sibling executions through configuredFor(...); it does not determine which credential was used during the current authentication. See the [current implementation](https://github.com/keycloak/keycloak/blob/main/services/src/main/java/org/keycloak/authentication/authenticators/conditional/ConditionalUserConfiguredAuthenticator.java).

Keycloak has a separate [ConditionalCredentialAuthenticator](https://www.keycloak.org/docs-api/latest/javadocs/org/keycloak/authentication/authenticators/conditional/ConditionalCredentialAuthenticator.html) for checking credentials used during the current authentication. The [authentication-flow documentation](https://github.com/keycloak/keycloak/blob/main/docs/documentation/server_admin/topics/authentication/flows.adoc) also describes this condition as the mechanism used to skip 2FA after a passwordless WebAuthn credential has been used.

Because of that, I would first verify whether the affected path is failing to:

record WebAuthnCredentialModel.TYPE_PASSWORDLESS in AuthenticationProcessor.AUTHN_CREDENTIALS; or
execute or configure the conditional-credential execution in the Conditional 2FA subflow.

The AuthenticatorUtil.getAuthnCredentials(...) implementation should help compare the authentication-session state between the working and failing cases.

I would avoid adding this check directly to ConditionalUserConfiguredAuthenticator unless the intended separation is confirmed. Otherwise, a passkey could disable any conditional user-configured branch, including flows where passkey plus OTP is intentionally required for step-up authentication.

The proposed integration tests are useful. I would additionally cover an explicitly required OTP/step-up flow and a custom flow using conditional-user-configured without conditional-credential, to ensure existing MFA behavior is preserved.

Could the core-authentication team confirm whether the regression is expected to be fixed in credential recording, conditional-credential evaluation, or flow configuration? I would be happy to adjust the candidate patch once that behavior is confirmed.

1 reply

VivekanandChoudhary09 Sep 18, 2026
Author

Thanks, that feedback makes sense. I rechecked the code path and agree that changing
ConditionalUserConfiguredAuthenticator is the wrong layer, so I removed that change.

I verified that passwordless WebAuthn already reports WebAuthnCredentialModel.TYPE_PASSWORDLESS
through WebAuthnPasswordlessAuthenticator#getCredentialType(), and successful WebAuthn
authentication calls context.success(getCredentialType()). AuthenticationProcessor.success(String)
then records that value in AUTHN_CREDENTIALS via AuthenticatorUtil.addAuthCredential(...).

I also checked ConditionalCredentialAuthenticator and the default Browser flow configuration.
The default Browser - Conditional 2FA flow is configured with conditional-credential using
WebAuthnCredentialModel.TYPE_PASSWORDLESS, so the writer and reader both use the same
credential type: "webauthn-passwordless".

So the updated fix does not add passkey-awareness to ConditionalUserConfiguredAuthenticator.
Instead, it restores that authenticator to its original responsibility and updates the tests
to protect the intended separation:

default Browser flow + passkey login + OTP configured: OTP is skipped via conditional-credential;
custom flow with conditional-user-configured but without conditional-credential: passkey does
not bypass OTP;
password login with OTP configured still requires OTP.

This should preserve the step-up/custom-flow behavior you called out while keeping the passkey
skip logic in ConditionalCredentialAuthenticator, which matches the docs.

Files changed:

services/src/main/java/org/keycloak/authentication/authenticators/conditional/ConditionalUserConfiguredAuthenticator.java (reverted to original behavior)
testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/webauthn/passwordless/PasskeysDefaultBrowserFlowTest.java (new coverage above)

One open question this raises: since both the credential-recording and conditional-credential
evaluation were already correct on the default flow, I don't yet have a confirmed explanation
for what originally triggered the regression report. If the original reporter has a specific
realm export or a non-default flow config, I'd like to check that directly — it's possible the
issue only reproduces on a custom/migrated flow missing the conditional-credential execution,
rather than the default flow.

Also flagging: I've confirmed a clean compile of the services module, but couldn't run the new
integration tests locally due to missing Maven snapshot dependencies in this checkout. I'll get
CI to run them before this goes further, or can run them myself if there's a way to pull the
missing snapshots.

Navigation Menu

Repository navigation

Passkey login still prompts for OTP when Realm Passkeys is enabled (#52809) #52876

8000 Uh oh!

{{title}}

Uh oh!

Replies: 1 comment 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Passkey login still prompts for OTP when Realm Passkeys is enabled (#52809) #52876

8000 Uh oh!

VivekanandChoudhary09 Sep 17, 2026

Replies: 1 comment · 1 reply

Uh oh!

lubineitor Sep 17, 2026

Uh oh!

VivekanandChoudhary09 Sep 18, 2026 Author

VivekanandChoudhary09
Sep 17, 2026

Replies: 1 comment 1 reply

lubineitor
Sep 17, 2026

VivekanandChoudhary09 Sep 18, 2026
Author