Skip to content

fix(yubikey): fall back to the RP ID origin when the server sends no appid - #2444

Draft
maksimu wants to merge 1 commit into
releasefrom
fix/webauthn-origin-fallback
Draft

maksimu wants to merge 1 commit into
releasefrom
fix/webauthn-origin-fallback

Conversation

@maksimu

@maksimu maksimu commented Oct 16, 2026

Copy link
Copy Markdown
Collaborator

Security-key login from Commander fails with two_factor_code_invalid against a Keeper server on localhost, which is how a default Self-Managed Keeper install runs. yubikey_authenticate takes the client origin only from the appid extension. keeperapp leaves appid out when its hostname starts with local (WebAuthnUtil.createRelyingParties), so Commander signs "origin":"" and the server rejects the assertion. The web vault sends https://localhost on the same server and passes.

With no appid, the origin is now https://<rpId>, the same thing the biometric client already does. When appid is present nothing changes, and the legacy U2F retry still uses appid for its RP ID.

I checked with fido2 2.2.1 that the collector now produces https://localhost for that case and still uses appid when one is sent. I haven't tested it with a hardware key against SMK yet.

…appid

yubikey_authenticate took the WebAuthn client origin only from the appid
extension. keeperapp omits appid when its host is local (localhost, as on a
default Self-Managed Keeper install), so Commander signed an empty origin and
2fa_validate rejected the assertion with two_factor_code_invalid. Use
https://<rpId> instead, as the biometric client already does. The legacy U2F
retry still uses appid as before.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant