OpenID Connect

The OpenID Connect Provider role is a very useful but complex feature to enhance interoperability of Authelia with other products.

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 as of now. OpenID Connect and it’s related endpoints are not enabled by default unless you specifically configure the OpenID Connect section.

As OpenID Connect is fairly complex (the OpenID Connect Provider role especially so) it’s intentional that it is both a beta and that the implemented features are part of a thoughtful roadmap. Items that are not immediately obvious as required (i.e. bug fixes or spec features), will likely be discussed in team meetings or on GitHub issues before being added to the list. We want to implement this feature in a very thoughtful way in order to avoid security issues.

Stages #

This section represents the stages involved in implementation of this feature. The stages are either in order of implementation due to there being an underlying requirement to implement them in this order, or in a rough order due to how important or difficult to implement they are.

Beta 1 #

Feature List:

• 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
• Confidential Client Type

Beta 2 #

Feature List:

• Userinfo Endpoint
• Parameter Entropy
• Token/Code Lifespan
• Client Debug Messages
• Client Audience
• Public Client Type

Beta 3 #

Feature List:

• Proof Key Code Exchange (PKCE) for Authorization Code Flow
• Claims:
  • preferred_username - sending the username in this claim instead of the sub claim.

Beta 4 #

Feature List:

• Persistent Storage
  • Tokens
  • Auditable Information
  • Subject to User Mapping
• Opaque RFC4122 UUID v4’s for subject identifiers
• Support for Pairwise and Plain subject identifier types as per OpenID Connect Core (Subject Identifier Types)
  • Utilize the pairwise example method 3 as per OpenID Connect Core (Pairwise Identifier Algorithm)
• Claims:
  • sub - replace username with opaque random RFC4122 UUID v4
  • amr - authentication method references as per RFC8176
  • azp - authorized party as per OpenID Connect Core (ID Token)
  • client_id - the Client ID as per RFC8693 Section 4.3
• Cross Origin Resource Sharing (CORS):
  • Automatically allow all cross-origin requests to the discovery endpoints
  • Automatically allow all cross-origin requests to the JSON Web Keys endpoint
  • Optionally allow cross-origin requests to the other endpoints individually

Beta 5 #

Feature List:

• JWK’s backed by X509 Certificate Chains
• Hashed Client Secrets
• Per-Client Consent Mode:
  • Explicit:
    • The default
    • Always asks for end-user consent
  • Implicit:
    • Not expressly standards compliant
    • Never asks for end-user consent
    • Not compatible with the consent prompt type
  • Pre-Configured:
    • Allows users to save consent sessions for a duration configured by the administrator
    • Operates nearly identically to the explicit consent mode

Beta 6 #

• OAuth 2.0 Pushed Authorization Requests

Beta 7 #

Feature List:

• Prompt Handling
• Display Handling

See OpenID Connect Core (Mandatory to Implement Features for All OpenID Providers).

Beta 8 #

Feature List:

• Revoke Tokens on User Logout or Expiration
• JSON Web Key Rotation

General Availability #

Feature List:

• Enable by Default
• Only after all previous stages are checked for bugs

Miscellaneous #

This stage lists features which individually do not fit into a specific stage and may or may not be implemented.

OpenID Connect Dynamic Client Registration #

See the OpenID Connect website for the OpenID Connect Dynamic Client Registration specification.

OpenID Connect Back-Channel Logout #

See the OpenID Connect website for the OpenID Connect Back-Channel Logout specification.

Should be implemented alongside Dynamic Client Registration.

OpenID Connect Front-Channel Logout #

See the OpenID Connect website for the OpenID Connect Front-Channel Logout specification.

Should be implemented alongside Dynamic Client Registration.

OAuth 2.0 Authorization Server Metadata #

See the IETF Specification RFC8414 for more information.

OpenID Connect Session Management #

See the OpenID Connect website for the OpenID Connect Session Management specification.

End-User Scope Grants #

Allow users to choose which scopes they grant.

Client RBAC #

Allow clients to be configured with a list of users and groups who have access to them.

Preferred Username Claim #

The preferred_username claim was missing and was fixed.