* 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.
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>
* admin api: make email primary when user has no emails
* utils: move get updated user and webhook trigger to utils to reduce duplicated code
* events: remove unused user and email event - Check is replaced with string variant
* remove unused dtos
* fix tests after changes
* webhook tests: switch to test.Suite instead of TestPersister -> added deprecation annotation to test.NewPersister
* Email Verification: Fix trigger of webhook when email verification is enabled and a email is created but not validated
Closes: #692, #1051
* add tests for webhooks
* improve error handling when context does not contain webhook manager
* add logging to worker and fix nesting error overwrite
* remove enable and disable methods in favor for update method
* move data in jwt from subject claim to custom `data` claim
* add event in jwt to custom `evt` claim
* change webhook trigger to only fire once per hook (was once per subscribed event in hook before)
Closes#692
* add webhooks settings to config
* add webhooks entity for database
* add endpoints for webhooks
* add worker for asynchronously executing webhooks
* add trigger for events to user change/create/delete users/emails
Closes#692
