Add FIDO2/WebAuthn (security key) support for Authentik#1529
Open
arharovets wants to merge 2 commits into
Open
Add FIDO2/WebAuthn (security key) support for Authentik#1529arharovets wants to merge 2 commits into
arharovets wants to merge 2 commits into
Conversation
The Authentik provider only answers the `ak-stage-authenticator-validate` stage with a typed code (TOTP/static), so users whose Authentik account uses a tap-only FIDO2/WebAuthn security key cannot log in via the CLI at all. The only workaround is the Browser provider but it requires Playwright which only works on Ubuntu. When the `authenticator-validate` stage offers a webauthn device and no `--mfa-token` is supplied, we perform a FIDO assertion against the hardware key and submit it as the `webauthn` field, instead of submitting a blank code. This reuses the shared FIDO client already used by the Okta and Keycloak providers (`okta.NewFidoClient`/`ChallengeU2F` over `go-u2fhost`). The behaviour is fully backward compatible: TOTP users keep passing `--mfa-token` (the code path is unchanged), and responses without a webauthn device fall through to the existing code path. Note: this uses the U2F/CTAP1 path, which works for tap-only keys where user verification is not required. Additionally, this preserves `loginDetails.URL`: `authentikContext` now carries its own working url field; `updateURL` mutates that instead of `loginDetails.URL`. Previously, the entry URL was overwritten with the final flow step so `SaveCredentials` stored the password under the wrong key and the saved password was never found on later runs (constant re-prompting; the keychain "Get returned error … item could not be found" message), and the SAML cache key was likewise corrupted.
arharovets
changed the title
doPostQuery ignores the error from res.Location(): a non-redirect response with no Location header (4xx/5xx from a WAF or upstream, or a redirect missing the header) makes res.Location() return (nil, ErrNoLocation), so loc.String() dereferences a nil *url.URL and panics. Return a wrapped error including the status code instead.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Authentik provider only answers the
ak-stage-authenticator-validatestage with a typed code (TOTP/static), so users whose Authentik account uses a tap-only FIDO2/WebAuthn security key cannot log in via the CLI at all. The only workaround is the Browser provider but it requires Playwright which only works on Ubuntu.When the
authenticator-validatestage offers a webauthn device and no--mfa-tokenis supplied, we perform a FIDO assertion against the hardware key and submit it as thewebauthnfield, instead of submitting a blank code. This reuses the shared FIDO client already used by the Okta and Keycloak providers (okta.NewFidoClient/ChallengeU2Fovergo-u2fhost).The behaviour is fully backward compatible: TOTP users keep passing
--mfa-token(the code path is unchanged), and responses without a webauthn device fall through to the existing code path.Note: this uses the U2F/CTAP1 path, which works for tap-only keys where user verification is not required.
Additionally, this preserves
loginDetails.URL:authentikContextnow carries its own working url field;updateURLmutates that instead ofloginDetails.URL. Previously, the entry URL was overwritten with the final flow step soSaveCredentialsstored the password under the wrong key and the saved password was never found on later runs (constant re-prompting; the keychain "Get returned error … item could not be found" message), and the SAML cache key was likewise corrupted.