* feat: add auth prompt config option
* feat: add pkce oauth flow
When the oauth flow is initialized with a `code_verifier` the state cookie is optional and on hanko_token exchange the client must also send the `code_verifier` in addition to the `hanko_token`.
* fix: fix runtime errors & tests
Rename identities table columns for more clarity. Rename parameters,
arguments etc. to accommodate these changes.
Change that the SAML provider domain is persisted in the identities
table as the provider ID. Use the SAML Entity ID/Issuer ID of the
IdP instead.
Introduce saml identity entity (including migrations and a persister)
as a specialization of an identity to allow for determining the
correct provider name to return to the client/frontend and for assisting
in determining whether an identity is a SAML identity (i.e. SAML
identities should have a corresponding SAML Identity instance while
OAuth/OIDC entities do not).
* feat: third party custom providers
- New configuration option `third_party.custom_providers`. `custom_providers`
is a map of arbitrarily chosen keys to a `CustomThirdPartyProvider` - this is
implemented as a new type differing from the existing configuration type
`ThirdPartyProvider` used for built-in providers because they have different
configuration requirements.
- Both `ThirdPartyProvider` and `CustomThirdPartyProvider` types get a non-
configurable, automatically populated `Name` (during the config's `PostProcess`)
that sort of serves as an identifier/slug for the provider in order to
distinguish provider types at runtime.
- A `CustomThirdPartyProvider`s `Name` is automatically prefixed during
`PostProcess` with a "custom_" prefix to ensure that providers can be
distinguished at runtime.
- A (built-in) `ThirdPartyProvider`s `Name` is "hard-coded" through the
`DefaultConfig`.
- Built-in OAuth/OIDC provider implementations are currently instantiated
on-demand instead of once at appliation startup (i.e. unlike SAML
providers) - i.e. when a user requests auth/authz with a third party
provider, only then a provider is instantiated and created via factory
function (`thirdparty.GetProvider`). Custom providers follow this
pattern, hence the factory function had to be adjusted to take into account
providers with the aforementioned "custom_" prefix (i.e.: if it is a
"custom_" provider, instantiate a `customProvider` implementation).
- The `customProvider` implementation uses the `go-oidc` library. Instances
of providers of the type this library offers can be instantiated by passing
in an `issuer` URL. Such an instantiation automatically attempts to retrieve
an OIDC discovery document from a `.well-known` endpoint. This also performs
an issuer validation. Providers configured to not use OIDC discovery (i.e.
`use_discovery` in the `CustomThirdPartyProvider` is `false` or omitted) do
not do this issuer check.
- The `customProvider` implementation is further based on the assumption that
provider user data is only extracted from a userinfo endpoint response, i.e.
in case of an OIDC provider, the implementation does not make use of the ID
token - no validation is performed on the ID token.
- The `customProvider` implementation requires configuring a list of `scopes`:
because the custom providers allow configuring both OAuth as well as OIDC
providers, we cannot simply set a default set of scopes, e.g. `openid`, which
is a required claim for OIDC - some providers return errors on unknown claims
so setting this would make the third party auth process prone to errors.
- The `customProvider` implementation allows for a simple mapping of claims
contained in the userinfo response from the provider to "known" standard OIDC
conformant claims at the Hanko backend (defined in the `thirdparty.Claims`
struct) through an `attribute_mapping` configuration option. The mapping is a
simple one-to-one mapping, i.e. no complex mapping instructions are possible,
e.g. mapping concatenations of multiple claims in the provider data source or
similar. Any other non-standard claims returned by the provider are placed in
a `custom_claims` attribute. Except for the user ID (`sub`), `email` and
`email_verified` claims the third party functionality currently does not allow
accessing this user data but there's a good chance this will change in the future,
so I tried to make sure that any info retrieved from the provider is somehow
preserved (it is persisted in the `data` column for an `identity` btw. and updated
on every login with the provider).
- I also noticed that the `thirdparty.Claims` were missing the `address` claim,
so I added that for completeness' sake.
- The changes also fix a "bug" in the account `linking` logic whereby third party
connections were established by simply assuming that the email retrieved from the
provider was verified. So, even if the email address at the provider was not
verified (or the provider simply did/does not provide info about the verification
status) an account was created and/or linked and the flow API capabilities of
automatically triggering a passcode if the backend was configured to require email
verification would not take effect. This was a wrong assumption and the verification
status is now based on the actual value retrieved from the provider.
- In case of a triggered passcode, the changes also modify the token exchange
action to prevent showing a `back` button/link, since it does not make sense to
go `back` to anything right after the token exchange - there is nothing to go
"back" to.
* feat: create otp_secrets table
* feat: create otp secret model
* feat: add mfa_only column to webauthn_credentials table
* feat: add mfa only field to webauthn credential model
* feat: add mfa config (#1607)
* feat: add otp secret persister (#1613)
* feat: MFA usage sub flow (#1614)
* feat: add mfa-usage sub-flow
---------
Co-authored-by: Lennart Fleischmann <67686424+lfleischmann@users.noreply.github.com>
* feat: include platform authenticator availybility in the preflight flow (#1615)
* feat: add mfa creation subflow
* feat: adjust registration flow
* feat: integrate mfa usage sub-flow
* feat: add pages for mfa (#1622)
* feat: profile flow adjustments for mfa support
* fix: suspension logic for mfa deletion actions
* feat: use dedicated action for security key creation options
* fix: mfa method stash entry can be stale on profile flow
The mfa_creation subflow sets an mfa_method stash value so that
when creating and persisting the credential the mfa_only flag can
be set correctly in the hook responsible for that. But the profile flow
never "ends" and and returns to the initial state so I can also
register a passkey afterwards. The mfa_method stash key remains on the
stash but is used in the hook nonetheless, so the passkey is incorrectly
recognized as a security key.
The mfa_method key is now deleted after successfully persisting the
credential/security_key. This should not have an effect on the login
flow because the mfa_creation subflow is the last subflow to be
executed. It also should not affect the registration flow, because the
hook is not applied in the registration flow (persistence of data is
all handled in the create_user hook).
* feat: add new icons and english translations (#1626)
* fix: credential id encoding corrected (#1628)
* feat: add audit logs for mfa creation
* feat: add a skip link to the mfa method chooser (#1630)
* feat: save the security key during login (#1629)
* feat: show security keys in profile
* feat: add authenticator app management to profile (#1633)
* feat: add authenticator app management to profile
* feat: passkey counts as second factor
* feat: prohibit security key first factor usage
* feat: add all WA creds to exclude list on registration
* refactor: mfa stash entries and webauthn credential persistence
Renames MFA stash entry for indicating usage (login) method to make its
meaning more explicit. Also removes code persisting a webauthn credential
from the attestation verification action in the onboarding flow because
this is already done by a shared hook.
* refactor: simplify WA creation call
Co-authored-by: bjoern-m <56024829+bjoern-m@users.noreply.github.com>
* chore: adjust mfa flow
* fix: mfa onboarding always shown during login
* fix: mfa onboarding not shown after password or email creation during login
* fix: mfa onboarding not shown without user detail onboarding
* fix: correct skip/back behaviour
* feat: reuse generated otp secret when the code is invalid
* chore: skip mfa prompt if the user only has a passkey
* chore: adjust login flow
* chore: skip mfa prompt if the user only has a passkey
* chore: refactor and improve mfa onboarding
* fix: no mfa onboarding when passwords and passkeys are disabled
* fix: only show mfa onbooarding once
* feat: add a function to the flowpilot to check whether a state has been visited
* chore: adjust recovery flow (#1655)
* feat: disable password, passcode endpoints when mfa enabled
* Feat: remember last used login method (#1674)
* chore: remove omitempty from boolean (#1676)
* chore: improved error handling (#1679)
* chore: improved error handling
* feat: add missing translations (#1681)
* feat: update aaguid list (#1678)
* fix: do not suspend webauthn action for MFA (#1778)
Do not suspend the `webauthn_verify_attestation_response` action when passkeys are disabled, but security keys and MFA are enabled.
* fix: change texts (#1785)
Change texts regarding security creation to be more consistent across the flows and to be more precise.
* Fix: UI issues (#1846)
* fix: loading spinner alignment corrected
* fix: auth app deletion link is shown while deletion is not allowed
* Chore: remove test persister (#1876)
* chore: remove deprecated test persister
* chore: replace test persister calls
* chore: add saml state fixtures
* Update backend/flow_api/services/webauthn.go
Co-authored-by: Frederic Jahn <frederic.jahn@hanko.io>
* Update backend/dto/profile.go
Co-authored-by: Frederic Jahn <frederic.jahn@hanko.io>
* fix: otp validation uses the rate limiter key for passwords
* chore: add otp-limits to the default config
* chore: add explanation for 'UserVerification' setting on security keys
---------
Co-authored-by: Lennart Fleischmann <lennart.fleischmann@hanko.io>
Co-authored-by: Lennart Fleischmann <67686424+lfleischmann@users.noreply.github.com>
Co-authored-by: Frederic Jahn <frederic.jahn@hanko.io>
This pull request introduces the new Flowpilot system along with several new features and various improvements. The key enhancements include configurable authorization, registration, and profile flows, as well as the ability to enable and disable user identifiers (e.g., email addresses and usernames) and login methods.
---------
Co-authored-by: Frederic Jahn <frederic.jahn@hanko.io>
Co-authored-by: Lennart Fleischmann <lennart.fleischmann@hanko.io>
Co-authored-by: lfleischmann <67686424+lfleischmann@users.noreply.github.com>
Co-authored-by: merlindru <hello@merlindru.com>
