--- layout: default title: OpenID Connect parent: Identity Providers grand_parent: Configuration nav_order: 2 --- # OpenID Connect **Authelia** currently supports the [OpenID Connect] OP role as a [beta](#beta) feature. The OP role is the [OpenID Connect] Provider role, not the Relaying Party or RP role. This means other applications that implement the [OpenID Connect] RP role can use Authelia as an authentication and authorization backend similar to how you may use social media or development platforms for login. The Relaying Party role is the role which allows an application to use GitHub, Google, or other [OpenID Connect] providers for authentication and authorization. We do not intend to support this functionality at this moment in time. ## Beta We have decided to implement [OpenID Connect] as a beta feature, it's suggested you only utilize it for testing and providing feedback, and should take caution in relying on it in production. [OpenID Connect] and it's related endpoints are not enabled by default unless you specifically configure the [OpenID Connect] section. The beta will be broken up into stages. Each stage will bring additional features. The following table is a *rough* plan for which stage will have each feature, and may evolve over time:

Stage	Feature Description
beta1	User Consent
	Authorization Code Flow
	OpenID Connect Discovery
	RS256 Signature Strategy
	Per Client Scope/Grant Type/Response Type Restriction
	Per Client Authorization Policy (1FA/2FA)
	Per Client List of Valid Redirection URI's
beta2 ¹	Userinfo Endpoint (missed in beta1)
beta3 ¹	Token Storage
beta3 ¹	Audit Storage
beta4 ¹	Back-Channel Logout
	Deny Refresh on Session Expiration
	Signing Key Rotation Policy
	Client Secrets Hashed in Configuration
GA ¹	General Availability after previous stages are vetted for bug fixes
misc	List of other features that may be implemented
misc	Front-Channel Logout ²

*¹ this stage has not been implemented as of yet* *² this individual feature has not been implemented as of yet* ## Configuration ```yaml identity_providers: oidc: hmac_secret: this_is_a_secret_abc123abc123abc issuer_private_key: | --- KEY START --- KEY END access_token_lifespan: 1h authorize_code_lifespan: 1m id_token_lifespan: 1h refresh_token_lifespan: 720h enable_client_debug_messages: false clients: - id: myapp description: My Application secret: this_is_a_secret authorization_policy: two_factor redirect_uris: - https://oidc.example.com:8080/oauth2/callback scopes: - openid - groups - email - profile grant_types: - refresh_token - authorization_code response_types: - code response_modes: - form_post - query - fragment userinfo_signing_algorithm: none ``` ## Options ### hmac_secret

type: string {: .label .label-config .label-purple } required: yes {: .label .label-config .label-red }

The HMAC secret used to sign the [OpenID Connect] JWT's. The provided string is hashed to a SHA256 byte string for the purpose of meeting the required format. Can also be defined using a [secret](../secrets.md) which is the recommended for containerized deployments. ### issuer_private_key

type: string {: .label .label-config .label-purple } required: yes {: .label .label-config .label-red }

The private key in DER base64 encoded PEM format used to encrypt the [OpenID Connect] JWT's. This can easily be generated using the Authelia binary using the following syntax: ```console authelia rsa generate --dir /config ``` Can also be defined using a [secret](../secrets.md) which is the recommended for containerized deployments. ### access_token_lifespan

type: duration {: .label .label-config .label-purple } default: 1h {: .label .label-config .label-blue } required: no {: .label .label-config .label-green }

The maximum lifetime of an access token. It's generally recommended keeping this short similar to the default. For more information read these docs about [token lifespan]. ### authorize_code_lifespan

type: duration {: .label .label-config .label-purple } default: 1m {: .label .label-config .label-blue } required: no {: .label .label-config .label-green }

The maximum lifetime of an authorize code. This can be rather short, as the authorize code should only be needed to obtain the other token types. For more information read these docs about [token lifespan]. ### id_token_lifespan

type: duration {: .label .label-config .label-purple } default: 1h {: .label .label-config .label-blue } required: no {: .label .label-config .label-green }

The maximum lifetime of an ID token. For more information read these docs about [token lifespan]. ### refresh_token_lifespan

type: string {: .label .label-config .label-purple } default: 30d {: .label .label-config .label-blue } required: no {: .label .label-config .label-green }

The maximum lifetime of a refresh token. This should typically be slightly more the other token lifespans. This is because the refresh token can be used to obtain new refresh tokens as well as access tokens or id tokens with an up-to-date expiration. For more information read these docs about [token lifespan]. ### enable_client_debug_messages

type: boolean {: .label .label-config .label-purple } default: false {: .label .label-config .label-blue } required: no {: .label .label-config .label-green }

Allows additional debug messages to be sent to the clients. ### minimum_parameter_entropy

type: integer {: .label .label-config .label-purple } default: 8 {: .label .label-config .label-blue } required: no {: .label .label-config .label-green }

This controls the minimum length of the `nonce` and `state` parameters. ***Security Notice:*** Changing this value is generally discouraged, reducing it from the default can theoretically make certain scenarios less secure. It highly encouraged that if your OpenID Connect RP does not send these parameters or sends parameters with a lower length than the default that they implement a change rather than changing this value. ### clients A list of clients to configure. The options for each client are described below. #### id

type: string {: .label .label-config .label-purple } required: yes {: .label .label-config .label-red }

The Client ID for this client. Must be configured in the application consuming this client. #### description

type: string {: .label .label-config .label-purple } default: *same as id* {: .label .label-config .label-blue } required: no {: .label .label-config .label-green }

A friendly description for this client shown in the UI. This defaults to the same as the ID. #### secret

type: string {: .label .label-config .label-purple } required: yes {: .label .label-config .label-red }

The shared secret between Authelia and the application consuming this client. Currently this is stored in plain text. #### authorization_policy

type: string {: .label .label-config .label-purple } default: two_factor {: .label .label-config .label-blue } required: no {: .label .label-config .label-green }

The authorization policy for this client. Either `one_factor` or `two_factor`. #### redirect_uris

type: list(string) {: .label .label-config .label-purple } required: yes {: .label .label-config .label-red }

A list of valid callback URL's this client will redirect to. All other callbacks will be considered unsafe. The URL's are case-sensitive. #### scopes

type: list(string) {: .label .label-config .label-purple } default: openid, groups, profile, email {: .label .label-config .label-blue } required: no {: .label .label-config .label-green }

A list of scopes to allow this client to consume. See [scope definitions](#scope-definitions) for more information. #### grant_types

type: list(string) {: .label .label-config .label-purple } default: refresh_token, authorization_code {: .label .label-config .label-blue } required: no {: .label .label-config .label-green }

A list of grant types this client can return. It is recommended that this isn't configured at this time unless you know what you're doing. Valid options are: `implicit`, `refresh_token`, `authorization_code`, `password`, `client_credentials`. #### response_types

type: list(string) {: .label .label-config .label-purple } default: code {: .label .label-config .label-blue } required: no {: .label .label-config .label-green }

A list of response types this client can return. It is recommended that this isn't configured at this time unless you know what you're doing. Valid options are: `code`, `code id_token`, `id_token`, `token id_token`, `token`, `token id_token code`. #### response_modes

type: list(string) {: .label .label-config .label-purple } default: form_post, query, fragment {: .label .label-config .label-blue } required: no {: .label .label-config .label-green }

A list of response modes this client can return. It is recommended that this isn't configured at this time unless you know what you're doing. Potential values are `form_post`, `query`, and `fragment`. #### userinfo_signing_algorithm

type: string {: .label .label-config .label-purple } default: none {: .label .label-config .label-blue } required: no {: .label .label-config .label-green }