4.5 KiB
| title | description | lead | date | draft | images | menu | weight | toc | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Specific Information | Specific information regarding integrating the Authelia OpenID Connect Provider with an OpenID Connect relying party | Specific information regarding integrating the Authelia OpenID Connect Provider with an OpenID Connect relying party. | 2022-10-20T15:27:09+11:00 | false |
|
615 | true |
Generating Client Secrets
We strongly recommend the following guidelines for generating client secrets:
- Each client should have a unique secret.
- Each secret should be randomly generated.
- Each secret should have a length above 40 characters.
- The secrets should be stored in the configuration in a supported hash format. Note: This does not mean you configure the relying party / client application with the hashed version, just the secret value in the Authelia configuration.
- Secrets should only have alphanumeric characters as some implementations do not appropriately encode the secret when using it to access the token endpoint.
Authelia provides an easy way to perform such actions via the Generating a Random Password Hash guide. Users can
perform a command such as authelia crypto hash generate pbkdf2 --variant sha512 --random --random.length 72 command to
both generate a client secret with 72 characters which is printed and is to be used with the relying party and hash it
using PBKDF2 which can be stored in the Authelia configuration.
Plaintext
Authelia technically supports storing the plaintext secret in the configuration. This will likely be completely unavailable in the future as it was a mistake to implement it like this in the first place. While some other OpenID Connect 1.0 providers operate in this way, it's more often than not that they operating in this way in error. The current technical support for this is only to prevent massive upheaval to users and give them time to migrate.
As per RFC6819 Section 5.1.4.1.3 the secret should only be stored by the authorization server as hashes / digests unless there is a very specific specification or protocol that is implemented by the authorization server which requires access to the secret in the clear to operate properly in which case the secret should be encrypted and not be stored in plaintext. The most likely long term outcome is that the client configurations will be stored in the database with the secret both salted and peppered.
Authelia currently does not implement any of the specifications or protocols which require secrets being accessible in
the clear such as most notibly the client_secret_jwt grant and currently we no plans to implement any of these. As
such it's strongly discouraged and heavily deprecated and we instead recommended that users remove this from their
configuration entirely and use the Generating Client Secrets guide. At such a time as we
support one of these protocols we will very likely only allow plaintext for clients configured expressly for this
purpose i.e. a client that only allows client_secret_jwt and no other grants.
Plaintext is either denoted by the $plaintext$ prefix where everything after the prefix is the secret. In addition if
the secret does not start with the $ character it's considered as a plaintext secret for the time being but is
deprecated as is the $plaintext$ prefix.
Frequently Asked Questions
Why isn't my application able to retrieve the token even though I've consented?
The most common cause for this issue is when the affected application can not make requests to the Token Endpoint.
This becomes obvious when the log level is set to debug or trace and a presence of requests to the Authorization
Endpoint without errors but an absence of requests made to the Token Endpoint.
These requests can be identified by looking at the path field in the logs, or by messages prefixed with
Authorization Request indicating a request to the Authorization Endpoint and Access Request indicating a request
to the Token Endpoint.
All causes should be clearly logged by the client application, and all errors that do not match this scenario are clearly logged by Authelia. It's not possible for us to log requests that never occur however.