This is a meta commit for a feature originally implemented in 0a970aef8a documenting the change from using the username as a subject identifier to a specification compliant subject identifier in the form of RFC4122 UUID V4 subject identifiers. This is a required change in order to be compliant with the specification as per https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes. Relying parties which utilize the subject identifier / sub claim may need manual intervention in order to relink accounts. Users who have issues will have to consult with the documentation of their individual relying parties in order to relink accounts. Users who utilized the subject identifier as a means to provision their users are also encouraged to utilize the preferred_username claim from the profile scope.
This moves the OpenID Connect storage from memory into the SQL storage, making it persistent and allowing it to be used with clustered deployments like the rest of Authelia.
This adjusts the CORS headers appropriately for OpenID Connect. This includes responding to OPTIONS requests appropriately. Currently this is only configured to operate when the Origin scheme is HTTPS; but can easily be expanded in the future to include additional Origins.
* feat(oidc): oauth2 discovery and endpoint rename
This implements the oauth2 authorization server discovery document, adds tests to the discovery documents, implements an efficiency upgrade to these docs, and renames some endpoints to be uniform.
Implements Proof Key for Code Exchange for OpenID Connect Authorization Code Flow. By default this is enabled for the public client type and requires the S256 challenge method.
Closes#2921
This change adjusts several global options moving them into the server block. It additionally notes other breaking changes in the configuration.
BREAKING CHANGE: Several configuration options have been changed and moved into other sections. Migration instructions are documented here: https://authelia.com/docs/configuration/migration.html#4.30.0
This implements the public option for clients which allows using Authelia as an OpenID Connect Provider for cli applications and SPA's where the client secret cannot be considered secure.
Update and adjust OIDC documentation. This also adds information for users about RP's that have been tested.
Co-authored-by: Georg Lauterbach <44545919+aendeavor@users.noreply.github.com>
Co-authored-by: Clément Michaud <clement.michaud34@gmail.com>
Co-authored-by: Amir Zarrinkafsh <nightah@me.com>
Co-authored-by: James Elliott <james-d-elliott@users.noreply.github.com>
This is a required endpoint for OIDC and is one we missed in our initial implementation. Also adds some rudamentary documentaiton about the implemented endpoints.
* This gives admins more control over their OIDC installation exposing options that had defaults before. Things like lifespans for authorize codes, access tokens, id tokens, refresh tokens, a option to enable the debug client messages, minimum parameter entropy. It also allows admins to configure the response modes.
* Additionally this records specific values about a users session indicating when they performed a specific authz factor so this is represented in the token accurately.
* Lastly we also implemented a OIDC key manager which calculates the kid for jwk's using the SHA1 digest instead of being static, or more specifically the first 7 chars. As per https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-key#section-8.1.1 the kid should not exceed 8 chars. While it's allowed to exceed 8 chars, it must only be done so with a compelling reason, which we do not have.
This is so levels like warn and error can be used to exclude info or warn messages. Additionally there is a reasonable refactoring of logging moving the log config options to the logging key because there are a significant number of log options now. This also decouples the expvars and pprof handlers from the log level, and they are now configured by server.enable_expvars and server.enable_pprof at any logging level.
OpenID connect has become a standard when it comes to authentication and
in order to fix a security concern around forwarding authentication and authorization information
it has been decided to add support for it.
This feature is in beta version and only enabled when there is a configuration for it.
Before enabling it in production, please consider that it's in beta with potential bugs and that there
are several production critical features still missing such as all OIDC related data is stored in
configuration or memory. This means you are potentially going to experience issues with HA
deployments, or when restarting a single instance specifically related to OIDC.
We are still working on adding the remaining set of features before making it GA as soon as possible.
Related to #189
Co-authored-by: Clement Michaud <clement.michaud34@gmail.com>
