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.

OpenID Certified™#

Authelia is OpenID Certified™ to conform to the OpenID Connect™ protocol.

For more information read the Integration Documentation.

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)
• Removal of Legacy Endpoints

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#

Breaking Changes:

• Removal of plaintext passwords except in cases that explicitly require them (HMAC-based client auth methods)
• Rework of Consent Policy

Feature List:

• In-Storage Configuration:
  • JSON Web Key Rotation
  • Multi-Issuer Configuration (require one per Issuer URL)
  • Dynamic Client Registration:
    • Specification Based with Special Opaque Tokens (authelia_dcrt_*) as per OpenID Connect Dynamic Client Registration 1.0, RFC7591: OAuth 2.0 Dynamic Client Registration Protocol, and RFC7592: OAuth 2.0 Dynamic Client Registration Management Protocol
    • Via the 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
• Subject Sectoring:
  • Pairwise Pseudonymous Identifier (PPID)
  • Sector Identifier validation.

Potential Feature List:

• Injecting Bearer JSON Web Tokens into Requests (backend authentication)
• Revoke Tokens on User Logout or Expiration

Beta 9#

Feature List:

• OpenID Connect Session Management 1.0
• OpenID Connect Back-Channel Logout 1.0
• OpenID Connect Front-Channel Logout 1.0
• OpenID Connect RP-Initiated Logout 1.0
• OpenID Connect Client-Initiated Backchannel Authentication Flow 1.0 (CIBA)

Potential Feature List:

• Injecting Bearer JSON Web Tokens into Requests (backend authentication)
• Revoke Tokens on User Logout or Expiration

General Availability#

This stage will signify official stability guarantees surrounding this implemented feature.

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#

For more information see the RFC8414: OAuth 2.0 Authorization Server Metadata specification.

OAuth 2.0 Token Exchange#

For more information see the RFC8693: OAuth 2.0 Token Exchange specification.

OAuth 2.0 Dynamic Client Registration Protocol#

For more information see the OAuth 2.0 website for the RFC7591: OAuth 2.0 Dynamic Client Registration Protocol specification; and see both OAuth 2.0 Client Registration Management Protocol and OpenID Connect Dynamic Client Registration 1.0.

See also Beta 8.

OAuth 2.0 Dynamic Client Registration Management Protocol#

For more information see the OAuth 2.0 website for the RFC7592: OAuth 2.0 Dynamic Client Registration Management Protocol specification; and see both OAuth 2.0 Client Registration Protocol and OpenID Connect Dynamic Client Registration 1.0.

See also Beta 8.

OpenID Connect Dynamic Client Registration 1.0#

For more information see the OpenID Connect 1.0 website for the OpenID Connect Dynamic Client Registration 1.0 specification; and see both OAuth 2.0 Client Registration Protocol and OAuth 2.0 Client Registration Management Protocol.

See also Beta 8.

OpenID Connect Session Management 1.0#

For more information see the OpenID Connect 1.0 website for the OpenID Connect Session Management 1.0 specification.

See also Beta 9.

OpenID Connect Back-Channel Logout 1.0#

For more information see the OpenID Connect 1.0 website for the OpenID Connect Back-Channel Logout 1.0 specification.

Should be implemented at a similar time to Dynamic Client Registration.

See also Beta 9.

OpenID Connect Front-Channel Logout 1.0#

For more information see the OpenID Connect 1.0 website for the OpenID Connect Front-Channel Logout 1.0 specification.

Should be implemented at the same time, or just after OpenID Connect Dynamic Client Registration 1.0.

See also Beta 9.

OpenID Connect RP-Initiated Logout 1.0#

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

See also Beta 9.

OpenID Connect Client-Initiated Backchannel Authentication Flow 1.0 (CIBA)#

See the OpenID Connect 1.0 website for the OpenID Connect Client-Initiated Backchannel Authentication Flow 1.0 (CIBA) specification.

See also Beta 9.

OpenID Connect 1.0 FAPI 2.0 Security Profile#

This profile is a suite of security focused features and settings which comply with several financial requirements in various jurisdictions. While we’re not expressly targeting these financial institutions the security profile itself has many security-enhancing measures which everyone can benefit from.

See the OpenID Connect 1.0 website for the FAPI 2.0 Security Profile specification, and the FAPI 2.0 Attacker Model.

End-User Scope Grants#

Allow users to choose which scopes they grant. It may be better to just allow optional claims and to avoid implementing this feature all together.

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.