1.9 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-06-15T17:51:47+10: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 authelia crypto hash generate command. 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 supports storing the plaintext secret in the configuration. This may be discontinued in the future. 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.