OpenID Connect 1.0 Provider

We have decided to implement OAuth 2.0 and OpenID Connect 1.0 as a beta feature. While it’s relatively stable there may inevitably be the occasional breaking change as we carefully implement each aspect of the relevant specifications. It’s suggested to use a bit more caution with this feature than most features, we do however greatly appreciate your feedback. OpenID Connect 1.0 and it’s related endpoints are not enabled by default unless you explicitly configure the OpenID Connect 1.0 Provider Configuration and OpenID Connect 1.0 Registered Clients sections.

As OpenID Connect 1.0 is fairly complex (the OpenID Connect 1.0 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 1.0
• 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:

• RFC7636: Proof Key for 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 1.0 (Subject Identifier Types)
  • Utilize the pairwise example method 3 as per OpenID Connect Core 1.0 (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 1.0 (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#

• RFC9068: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
• RFC9126: OAuth 2.0 Pushed Authorization Requests
• RFC9207: OAuth 2.0 Authorization Server Issuer Identification
• RFC6750: OAuth 2.0 Bearer Token Usage
• JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)
• JWT Response for OAuth Token Inspection
• RFC7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants:
  • Client Auth Method client_secret_jwt
  • Client Auth Method private_key_jwt
• Per-Client RFC7636: Proof Key for Code Exchange (PKCE) Policy
• Per-Client Token Lifespans
• OAuth 2.0 Client Credentials Grant
• Multiple Issuer JWKs:
  • RS256, RS384, RS512
  • PS256, PS384, PS512
  • ES256, ES384, ES512
• Client RBAC: Users and Groups:
  • Policies can be mapped to individual clients and reused
  • Match criteria is only subjects as this is the only effective thing that is deterministic during the life of an authorization

Beta 7#

Breaking Changes:

• Default ID Token Claims (related to Claims Handling)

Feature List:

• Prompt Handling
• Display Handling
• Claims Handling
  • Only include the required claims within the minted ID Token
  • Allow clients to use the claims parameter to request the claims which are included in the minted ID Token
  • Allow a user definable claims policy to allow access to custom claims and scopes
• Attribute Mapping
  • Custom Claims
  • Claims Policies
  • Expression Based Claims
• Custom Scopes
• RFC8628: OAuth 2.0 Device Authorization Grant
• JSON Web Encryption
• Client RBAC: Networks

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

Beta 8#

Feature List:

• Revoke Tokens on User Logout or Expiration
• JSON Web Key Rotation
• In-Storage Configuration:
  • Multi-Issuer Configuration (require one per Issuer URL)
  • Dynamically Configured via CLI
  • Import from YAML:
    • Manual method
    • Bootstrap method:
      • Defaults to one time only
      • Can optionally override the database configuration
  • Salt (random) and/or Peppered (storage encryption) Client Credentials

Potential Feature List:

• Injecting Bearer JSON Web Tokens into Requests (backend authentication)

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.

Multi-Issuer Configuration#

The initial design of our OpenID Connect 1.0 implementation was before Multi-Domain Protection was considered. It’s important for the future of Authelia that we carefully consider the implications of this and force users to configure a issuer per domain they wish to serve OpenID Connect 1.0 from and each of these are completely separate logical units.

OAuth 2.0 Authorization Server Metadata#

See the RFC8414: OAuth 2.0 Authorization Server Metadata specification for more information.

OpenID Connect Dynamic Client Registration 1.0#

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

OpenID Connect Session Management 1.0#

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

OpenID Connect Back-Channel Logout 1.0#

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

Should be implemented alongside Dynamic Client Registration.

OpenID Connect Front-Channel Logout 1.0#

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

Should be implemented alongside Dynamic Client Registration.

OpenID Connect RP-Initiated Logout 1.0#

See the OpenID Connect 1.0 website for the OpenID Connect RP-Initiated Logout 1.0 specification.

End-User Scope Grants#

Allow users to choose which scopes they grant.

Client RBAC: Users and Groups#

See also Beta 6 and Client RBAC: Networks.

Allow the creation of custom authorization policies for OpenID Connect 1.0. Allow the policies to contain either users or groups and an effective authorization policy applied to them from either one_factor, two_factor, or deny.

Allow these policies to be configured on one or more clients.

Client RBAC: Networks#

See also Beta 7 and Client RBAC: Users and Groups.

Allow enhancing the existing custom authorization policies to include networks.

Preferred Username Claim#

The preferred_username claim was missing and was fixed.