authelia/docs/content/en/integration/openid-connect/introduction.md

15 KiB

title description lead date draft images menu weight toc aliases
OpenID Connect An introduction into integrating the Authelia OpenID Connect Provider with an OpenID Connect relying party An introduction into integrating the Authelia OpenID Connect Provider with an OpenID Connect relying party. 2022-06-15T17:51:47+10:00 false
integration
parent
openid-connect
610 true
/docs/community/oidc-integrations.html

Authelia can act as an OpenID Connect 1.0 Provider as part of an open beta. This section details implementation specifics that can be used for integrating Authelia with an OpenID Connect 1.0 Relying Party, as well as specific documentation for some OpenID Connect 1.0 Relying Party implementations.

See the configuration documentation for information on how to configure the Authelia OpenID Connect 1.0 Provider.

Scope Definitions

openid

This is the default scope for OpenID Connect 1.0. This field is forced on every client by the configuration validation that Authelia does.

Important Note: The subject identifiers or sub Claim has been changed to a RFC4122 UUID V4 to identify the individual user as per the Subject Identifier Types section of the OpenID Connect 1.0 specification. Please use the preferred_username Claim instead.

Claim JWT Type Authelia Attribute Description
iss string hostname The issuer name, determined by URL
jti string(uuid) N/A A RFC4122 UUID V4 representing the JWT Identifier
rat number N/A The time when the token was requested
exp number N/A Expires
iat number N/A The time when the token was issued
auth_time number N/A The time the user authenticated with Authelia
sub string(uuid) opaque id A RFC4122 UUID V4 linked to the user who logged in
scope string scopes Granted scopes (space delimited)
scp array[string] scopes Granted scopes
aud array[string] N/A Audience
amr array[string] N/A An RFC8176 list of authentication method reference values
azp string id (client) The authorized party
client_id string id (client) The client id

offline_access

This scope is a special scope designed to allow applications to obtain a Refresh Token which allows extended access to an application on behalf of a user. A Refresh Token is a special Access Token that allows refreshing previously issued token credentials, effectively it allows the relying party to obtain new tokens periodically.

Generally unless an application supports this and actively requests this scope they should not be granted this scope via the client configuration.

groups

This scope includes the groups the authentication backend reports the user is a member of in the Claims of the ID Token.

Claim JWT Type Authelia Attribute Description
groups array[string] groups List of user's groups discovered via authentication

email

This scope includes the email information the authentication backend reports about the user in the Claims of the ID Token.

Claim JWT Type Authelia Attribute Description
email string email[0] The first email address in the list of emails
email_verified bool N/A If the email is verified, assumed true for the time being
alt_emails array[string] email[1:] All email addresses that are not in the email JWT field

profile

This scope includes the profile information the authentication backend reports about the user in the Claims of the ID Token.

Claim JWT Type Authelia Attribute Description
preferred_username string username The username the user used to login with
name string display_name The users display name

Parameters

The following section describes advanced parameters which can be used in various endpoints as well as their related configuration options.

Grant Types

The following describes the various [OAuth 2.0] and OpenID Connect 1.0 grant types and their support level. The value field is both the required value for the grant_type parameter in the authorization request and the grant_types configuration option.

Grant Type Supported Value Notes
OAuth 2.0 Authorization Code Yes authorization_code
OAuth 2.0 Resource Owner Password Credentials No password This Grant Type has been deprecated and should not normally be used
OAuth 2.0 Client Credentials Yes client_credentials
OAuth 2.0 Implicit Yes implicit This Grant Type has been deprecated and should not normally be used
OAuth 2.0 Refresh Token Yes refresh_token
OAuth 2.0 Device Code No urn:ietf:params:oauth:grant-type:device_code

Response Types

The following describes the supported response types. See the OAuth 2.0 Multiple Response Type Encoding Practices for more technical information.

Flow Type Values
Authorization Code Flow code
Implicit Flow token id_token
Implicit Flow id_token
Implicit Flow token
Hybrid Flow code token
Hybrid Flow code id_token
Hybrid Flow code token id_token

Response Modes

The following describes the supported response modes. See the OAuth 2.0 Multiple Response Type Encoding Practices for more technical information.

Name Value
Query String query
Fragment fragment
OAuth 2.0 Form Post form_post

Authentication Method References

Authelia currently supports adding the amr Claim to the ID Token utilizing the RFC8176 Authentication Method Reference values.

The values this Claim has are not strictly defined by the OpenID Connect 1.0 specification. As such, some backends may expect a specification other than RFC8176 for this purpose. If you have such an application and wish for us to support it then you're encouraged to create a feature request.

Below is a list of the potential values we place in the Claim and their meaning:

Value Description Factor Channel
mfa User used multiple factors to login (see factor column) N/A N/A
mca User used multiple channels to login (see channel column) N/A N/A
user User confirmed they were present when using their hardware key N/A N/A
pin User confirmed they are the owner of the hardware key with a pin N/A N/A
pwd User used a username and password to login Know Browser
otp User used TOTP to login Have Browser
hwk User used a hardware key to login Have Browser
sms User used Duo to login Have External

User Information Signing Algorithm

The following table describes the response from the UserInfo endpoint depending on the userinfo_signing_algorithm.

Signing Algorithm Encoding Content Type
none JSON application/json; charset="UTF-8"
RS256 JWT (Signed) application/jwt; charset="UTF-8"

Endpoint Implementations

The following section documents the endpoints we implement and their respective paths. This information can traditionally be discovered by relying parties that utilize OpenID Connect Discovery, however this information may be useful for clients which do not implement this.

The endpoints can be discovered easily by visiting the Discovery and Metadata endpoints. It is recommended regardless of your version of Authelia that you utilize this version as it will always produce the correct endpoint URLs. The paths for the Discovery/Metadata endpoints are part of IANA's well known registration but are also documented in a table below.

These tables document the endpoints we currently support and their paths in the most recent version of Authelia. The paths are appended to the end of the primary URL used to access Authelia. The tables use the url https://auth.example.com as an example of the Authelia root URL which is also the OpenID Connect issuer.

Well Known Discovery Endpoints

These endpoints can be utilized to discover other endpoints and metadata about the Authelia OP.

Endpoint Path
OpenID Connect Discovery https://auth.example.com/.well-known/openid-configuration
OAuth 2.0 Authorization Server Metadata https://auth.example.com/.well-known/oauth-authorization-server

Discoverable Endpoints

These endpoints implement OpenID Connect elements.

Endpoint Path Discovery Attribute
JSON Web Key Sets https://auth.example.com/jwks.json jwks_uri
Authorization https://auth.example.com/api/oidc/authorization authorization_endpoint
Token https://auth.example.com/api/oidc/token token_endpoint
UserInfo https://auth.example.com/api/oidc/userinfo userinfo_endpoint
Introspection https://auth.example.com/api/oidc/introspection introspection_endpoint
Revocation https://auth.example.com/api/oidc/revocation revocation_endpoint