* add sign in with facebook
* feat: add facebook provider to factory function
* feat: add facebook config defaults
* feat: use newest facebook api version
* feat: make facebook provider consistent with other providers
* feat: add check for email
We cannot assume a user always has a valid email.
Even though it is not the used "me" endpoint, see:
https://developers.facebook.com/docs/graph-api/reference/user/
* docs: elaborate comment
* fix: fix third party tests
* feat: add facebook icon
* feat: add appsecret_proof to requests w. access token
* refactor: build userinfo url programmatically
* feat: map all available name claims
---------
Co-authored-by: Prathamesh <psvagare@gmail.com>
* 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.
