Supported features

The compatibility reference for the identity provider: what an integrating application can depend on.

tip

For a live provider, the discovery document at /.well-known/openid-configuration gives the same facts in machine-readable form.

Endpoints

Paths are relative to the provider's issuer, e.g. https://accounts.example.com.

Endpoint	Path
Discovery (OpenID Connect)	/.well-known/openid-configuration
Discovery (OAuth 2.0 server metadata)	/.well-known/oauth-authorization-server
Authorization	/identity/authorize
Token	/identity/token
UserInfo	/identity/userinfo
JWKS (signing keys)	/identity/jwks.json
Device authorization	/identity/device_authorization
Device verification (for people)	/identity/device
End session (application-initiated logout)	/identity/logout
Token revocation	/identity/revoke
Token introspection	/identity/introspect
Dynamic client registration	/identity/register
Registration management	/identity/register/{client_id}

Flows and grant types

Grant	Notes
authorization_code	The primary flow. Always the code response type.
refresh_token	Issued only with the offline_access scope. Tokens rotate on each refresh.
urn:ietf:params:oauth:grant-type:device_code	The device flow, for clients with limited input.

Deliberately not offered

No implicit flow, hybrid flow, resource owner password grant, or client_credentials. The provider authenticates users, and the modern flows cover every shape of client.

Token lifetimes:

Token	Lifetime
Authorization codes and device codes	10 minutes
Access tokens	1 hour
Refresh tokens	1 month, rotating

Authorization requests and responses

• Response type: code only.
• Response modes: query (the default), form_post, and JARM (jwt, query.jwt, form_post.jwt). Use JARM for an application that wants a signed authorization response, or an encrypted one if it asks for that.
• PKCE: S256 only; plain is refused. Public clients must use PKCE.
• Every authorization response carries the iss parameter (RFC 9207), so a client can detect a mix-up attack.

Not supported

Request objects (JAR) and request_uri, pushed authorization requests (PAR), and the general claims request parameter. Its acr member is supported; see authentication strength.

Client authentication

These methods work at the token, revocation, and introspection endpoints:

Method	Notes
none	Public clients. PKCE is then mandatory.
client_secret_basic	HTTP Basic authentication.
client_secret_post	Credentials in the body.
client_secret_jwt	Assertions with HS256, HS384, or HS512.
private_key_jwt	Assertions with RS, PS, or ES, 256 to 512. The client needs a registered JWKS.

Tokens, signatures, and encryption

ID tokens	Signed with RS256 (the default), PS256, or ES256, selected per application.
Access tokens	JWTs of type at+jwt (RFC 9068) carrying iss, aud, sub, client_id, scope, and the session claims. A resource indicator (RFC 8707) sent by the client becomes the audience. Opaque reference tokens are also available where a JWT isn't right; a client validates them with introspection.
UserInfo	Plain JSON by default. Per application it can be signed with RS256, PS256, or ES256, encrypted, or both.
Introspection	Responses can be returned as a signed JWT of type token-introspection+jwt (RFC 9701).
Encryption	Where offered (UserInfo, JARM, introspection): RSA-OAEP, RSA-OAEP-256, A128/192/256KW, ECDH-ES, and its A…KW variants for key management; A128/192/256CBC-HS… and A128/192/256GCM for content.

note

ID tokens can't be encrypted.

Scopes and claims

Scope	Releases
openid	The stable subject identifier, sub.
profile	name, nickname, preferred_username, website, gender, birthdate, zoneinfo, locale
email	email, email_verified
address	address
phone	phone_number, phone_number_verified
offline_access	Nothing. It gives refresh tokens.
elpan:identities	The addresses the user can send as, as {email, name} pairs.
elpan:groups	elpan:groups: the addresses of the groups the user belongs to, as a list.

A scope's claims appear in the ID token and at the UserInfo endpoint. Every ID token also carries sid (the session ID), auth_time, acr, amr, and, in the code flow, nonce.

note

An application's scope policy decides which scopes it can actually receive.

Groups as roles

An application can map each group to a role, e.g. every member of admins@example.com is an administrator. You then grant the role by adding the person to the group in the panel; the application re-reads the membership at each sign-in.

The claim name contains a colon. Software that reads claims with a path expression such as JMESPath needs it quoted: "elpan:groups".

Authentication strength

An application asks for a strength with acr_values or the acr claim member, then reads back what the user used:

acr	Meaning	Possible amr values
1	Single factor	pwd
2	Multi-factor	pwd + otp + mfa, or pwd + mca + mfa
phr	Phishing-resistant	swk, a synchronizing passkey
phrh	Phishing-resistant, hardware-protected	hwk, a hardware-bound passkey such as a security key

• mca means the user approved the sign-in on one of their devices, a second channel. It's not phishing-resistant.
• mfa is added whenever more than one distinct method was involved, including a password session later strengthened by a passkey.
• A passkey's WebAuthn Backup Eligibility flag decides between phr and phrh. A key that can never leave its authenticator reports phrh and hwk; a synchronizing passkey reports phr and swk.

The provider asks for more; it doesn't refuse. A user who signs in below the requested level gets a passkey challenge if they enrolled a passkey, otherwise a one-time code challenge. When an application asks for multi-factor and the user has no second factor at all, the provider takes them through authenticator-app enrollment on the spot.

The unmet_authentication_requirements error (RFC 9470) is returned only when no such step can satisfy the request, e.g. phrh requested from a user with no hardware-bound passkey.

prompt=none, prompt=login, prompt=consent, prompt=select_account, and max_age are supported, for silent and forced re-authentication. The forced re-authentication page also lets a different user sign in, and prompt=select_account always shows the consent screen with its Sign in as another user.

When the user cancels the consent screen, the application gets the access_denied error with its state, in the response mode it asked for.

The trusted-computer shortcut never satisfies an acr_values request

A user who selects "Trust this computer for 30 days" at sign-in skips the one-time code prompt, and their session honestly reports acr: "1". An application asking for 2 still gets a real challenge.

Logout

• Application-initiated logout at the end-session endpoint, with id_token_hint and the registered post_logout_redirect_uris.
• Back-channel logout. A signed logout+jwt logout token carrying sid goes to each subscribed application.
• Front-channel logout. The logout page holds a logout frame per application, with iss and sid where needed.

When a user signs out of the portal, their sessions end across the applications.

note

The older session-management iframe, check_session_iframe, isn't implemented. Use the logout specifications above.

Dynamic registration

Registration (RFC 7591) and management (RFC 7592) are always available. Management covers read, update, and delete, with the registration access token issued at creation. The guardrails:

• a rate limit per IP address
• a cap on request size
• at most 100 dynamic clients per provider
• automatic deletion of unused clients

A dynamic client can use only the code and refresh grants.

Summary of the specifications

Implemented:

• OpenID Connect Core, Discovery, RP-Initiated Logout, Front-Channel Logout, and Back-Channel Logout.
• JARM and the form-post response mode.
• OAuth 2.0 (RFC 6749) with these extensions:

Extension	RFC
Bearer tokens	6750
PKCE, with S256	7636
Revocation	7009
JWT client assertions	7521 and 7523
Dynamic registration	7591 and 7592
Introspection	7662
Server metadata	8414
The device grant	8628
Resource indicators	8707
JWT access tokens	9068
Issuer identification	9207
Step-up authentication	9470
JWT introspection responses	9701

Not implemented:

• the implicit and hybrid flows
• the password and client-credentials grants
• PAR (RFC 9126)
• JAR and request_uri (RFC 9101)
• the general claims parameter
• ID token encryption
• OIDC Session Management
• plain PKCE