This adds support for JWK selection by ID on a per-client basis, and allows multiple JWK's for the same algorithm.
Signed-off-by: James Elliott <james-d-elliott@users.noreply.github.com>
This adds support for the private_key_jwt client authentication method.
Signed-off-by: James Elliott <james-d-elliott@users.noreply.github.com>
Co-authored-by: Amir Zarrinkafsh <nightah@me.com>
This adds support for multiple JWK algorithms and keys and allows for per-client algorithm choices.
Signed-off-by: James Elliott <james-d-elliott@users.noreply.github.com>
This adds the authentication machinery for the client_secret_jwt to the Default Client Authentication Strategy.
Signed-off-by: James Elliott <james-d-elliott@users.noreply.github.com>
This adds a feature to OpenID Connect 1.0 where clients can be restricted to a specific client authentication mode, as well as implements some backend requirements for the private_key_jwt client authentication mode (and potentially the tls_client_auth / self_signed_tls_client_auth client authentication modes). It also adds some improvements to configuration defaults and validations which will for now be warnings but likely be made into errors.
Signed-off-by: James Elliott <james-d-elliott@users.noreply.github.com>
This fixes an issue where attempting to load secrets the process does not have read permissions for would cause panics as well as the bit size check of the OpenID Connect 1.0 private key can potentially panic on malformed private keys. This was caused by us returning values on errors instead of nil's.
Fixes#5138
Signed-off-by: James Elliott <james-d-elliott@users.noreply.github.com>
This fixes an issue where redirect URIs which may be valid are rejected by the configuration validator. This will instead allow the OpenID Connect 1.0 flows to validate them individually.
This adds multiple consent modes to OpenID Connect clients. Specifically it allows configuration of a new consent mode called implicit which never asks for user consent.
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.
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 adds an access-control command that checks the policy enforcement for a given criteria using a configuration file and refactors the configuration validation command to include all configuration sources.
This commit replaces github.com/spf13/viper with github.com/knadh/koanf. Koanf is very similar library to viper, with less dependencies and several quality of life differences. This also allows most config options to be defined by ENV. Lastly it also enables the use of split configuration files which can be configured by setting the --config flag multiple times.
Co-authored-by: Amir Zarrinkafsh <nightah@me.com>
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.
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.
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>
James Elliott
Andrew Moore
Clément Michaud