Browser flow: OTP step in sibling ALTERNATIVE subflow still executes after successful Passkey authentication (26.6) #50442

dreerr · 2026-06-30T10:46:14Z

dreerr
Jun 30, 2026

Keycloak version: 26.6 (quay.io/keycloak/keycloak:26.6)

Goal: Authenticate via either Passkey (passwordless) OR Username+Password+OTP — mutually exclusive, not both required.

Flow structure:

Browser Flow
├── Cookie ......................... ALTERNATIVE
├── Identity Provider Redirector ... ALTERNATIVE
└── Auth-Forms ...................... ALTERNATIVE
    ├── Passkey-Login ................ ALTERNATIVE
    │   └── WebAuthn Passwordless Authenticator .. REQUIRED
    └── Password-OTP ................. ALTERNATIVE
        ├── Username Password Form ... REQUIRED
        └── OTP Form .................. REQUIRED

Steps to reproduce:

Test user has three credentials registered: Password, OTP (type otp, label "iPhone"), Webauthn-passwordless (type webauthn-passwordless, label "Passkey"). Confirmed via Admin Console → Users → Credentials tab.
Bind the above flow as the realm's browser flow.
Initiate login, authenticate via Passkey.

Expected: Successful Passkey authentication should satisfy the Auth-Forms ALTERNATIVE container, and the sibling Password-OTP subflow (including its OTP Form step) should be skipped entirely.

Actual: After successful Passkey authentication, the user is additionally prompted for an OTP code.

Isolation test: Setting Password-OTP to DISABLED makes the Passkey login succeed cleanly with no further prompts. This suggests the WebAuthn Passwordless Authenticator itself is functioning correctly, and the issue is specific to how the OTP Form step in the sibling subflow is evaluated relative to the already-successful Passkey-Login subflow.

Suspicion: Since the test user has an OTP credential registered, it's possible the OTP Form step is being evaluated/executed independently of the subflow's ALTERNATIVE status because Keycloak detects a configured OTP credential for the user, rather than the execution being skipped once a sibling ALTERNATIVE subflow has already succeeded.

Question: Is this expected behavior given how REQUIRED executions are evaluated within ALTERNATIVE subflows, or is this a bug in subflow short-circuiting logic? Is there a recommended flow structure in 26.x to achieve a clean either/or between Passkey and Password+OTP, or should this rely on Condition - Credential / Condition - User Configured to explicitly gate the Password-OTP branch instead of relying on ALTERNATIVE sibling exclusion?

Happy to provide full flow export (JSON) or server logs if useful.

Answered by darius-m

Jun 30, 2026

I'm not sure if the authentication flow goes through the passkey subflow, as you have set it up there. In the docs it seems like for that authentication step to work, it should be configured after a username form - https://www.keycloak.org/docs/latest/server_admin/index.html#creating-a-password-less-browser-login-flow (note that it may simply be an old setup and the team forgot to update the documentation in this particular case).

Version 26.3.0 appears to have integrated webauthn-passwordless authentication in the username/password form, as mentioned in the release notes https://github.com/keycloak/keycloak/releases/tag/26.3.0 and (somewhat, though it may need to be more clear) in the up…

View full answer

darius-m · 2026-06-30T11:33:52Z

darius-m
Jun 30, 2026

I'm not sure if the authentication flow goes through the passkey subflow, as you have set it up there. In the docs it seems like for that authentication step to work, it should be configured after a username form - https://www.keycloak.org/docs/latest/server_admin/index.html#creating-a-password-less-browser-login-flow (note that it may simply be an old setup and the team forgot to update the documentation in this particular case).

Version 26.3.0 appears to have integrated webauthn-passwordless authentication in the username/password form, as mentioned in the release notes https://github.com/keycloak/keycloak/releases/tag/26.3.0 and (somewhat, though it may need to be more clear) in the upgrade guide https://www.keycloak.org/docs/latest/upgrading/index.html#deprecation-of-the-passkeys-conditional-ui-authenticator

If you look at the (current) default browser flow (e.g., create a new test realm and look at the default flow inside it), you will see that theres a Condition - credential that explicitly checks that webauthn-passwordless was not used as a credential, despite there not being a passwordless authentication step in the flow.

I think that in your case authentication skips the passwordless subflow altogether and it goes to the other subflow, where the passkey is used in the (now) hybridized username/password + passkey form, and OTP is a required step afterwards.

3 replies

dreerr Jun 30, 2026
Author

~~But when I disable the Password-OTP Subflow I can successfully login, so the Passkey-Subflow definitely works. Is there any order the Alternates are processed?~~
I was able to get it working when I reconstructed the browser flow of a newly created realm, which has the following structure:

forms ............................................. ALTERNATIVE
│
├── Username Password Form ........................ REQUIRED
│
└── Browser - Conditional 2FA ...................... CONDITIONAL
    │
    ├── Condition - user configured ................ REQUIRED
    │     (passes if: OTP credential exists for user)
    │
    ├── Condition - credential ..................... REQUIRED
    │     (config: Credentials = webauthn-passwordless)
    │
    ├── OTP Form .................................... ALTERNATIVE
    │
    └── WebAuthn Authenticator ...................... ALTERNATIVE

darius-m Jun 30, 2026

Happy you were able to find a configuration that works. Regarding the original configuration I'd try changing the order of the subflows to see if anything changes, just to check whether there's something weird and Keycloak evaluates the last subflow first. As far as I can tell there are some cases where the order of "Alternative" steps matters and making a step first or last changes the behaviour; that being said, I don't recall Keycloak ever going to a different "Alternative" subflow and mixing between them. Once it decides on one subflow, it basically becomes "required" and all others are effectively disabled. This still has to be more thoroughly tested, though.

About your second implementation, I'd skip the "user configured" condition, since it will not correctly enforce using 2FA when used. Even if OTP is set as a required action, a user can simply delete it from their account and would never be asked to set it up again, allowing them to just use username+password to log in.

Since you are using a conditional flow, you will likely need to create a "required" subflow that does OTP inside the conditional flow, similar to what is described in the "Motivation" section of #31934. Note that the same observation about the order of "alternative" executions still counts and you may need to reorder them to get Keycloak to enforce MFA properly, while offering the option to configure MFA on first login or after all MFA options are removed from the account.

N.B., re-reading the message I just remembered that Keycloak may handle alternative sub-flows by trying to see which flow is able to complete and going for that one; as such, you may not be able to switch between passwordless and user+password in the first flow you've described, even if you get the result where you log in via passkey and are then no longer asked for OTP.

dreerr Jun 30, 2026
Author

Yes you are right, 8000 my first flow didn't catch enrolling for OTP, big problem!
This should work:

forms ............................................ ALTERNATIVE
│
├── Username Password Form ........................ REQUIRED
│
├── WebAuthn Passwordless Authenticator ........... ALTERNATIVE
│
└── Browser - Conditional OTP ..................... CONDITIONAL
    │
    ├── Condition - credential ..................... REQUIRED
    │     alias: if-no-webauthn-passwordless
    │     Credentials = webauthn-passwordless
    │     Included = Off   (negated: passes when user does
    │                       NOT have this credential)
    │
    └── OTP Form .................................... REQUIRED

Navigation Menu

Repository navigation

Browser flow: OTP step in sibling ALTERNATIVE subflow still executes after successful Passkey authentication (26.6) #50442

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 1 comment 3 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Browser flow: OTP step in sibling ALTERNATIVE subflow still executes after successful Passkey authentication (26.6) #50442

Uh oh!

Uh oh!

dreerr Jun 30, 2026

Replies: 1 comment · 3 replies

Uh oh!

darius-m Jun 30, 2026

Uh oh!

Uh oh!

dreerr Jun 30, 2026 Author

Uh oh!

darius-m Jun 30, 2026

Uh oh!

dreerr Jun 30, 2026 Author

dreerr
Jun 30, 2026

Replies: 1 comment 3 replies

darius-m
Jun 30, 2026

dreerr Jun 30, 2026
Author

dreerr Jun 30, 2026
Author