OpenID Connect Core 1.0 — Versola Docs
/docs
Pre-1.00.7.5versola.ioGitHub
RUEN

OpenID Connect Core 1.0

Which OpenID Connect Core 1.0 features Versola implements — flows, ID token, UserInfo, request parameters and claims.

Specification: OpenID Connect Core 1.0

OpenID Connect adds an identity layer on top of OAuth 2.0. It introduces the ID token, the UserInfo endpoint and a standard set of user claims.

Status

Partially implemented. Checked claims: 38 of 45.

Flows

  • Authorization Code Flow (response_type=code)
  • Hybrid Flow with response_type=code id_token — nonce is required and the response defaults to the fragment (HybridFlowSpec)
  • Implicit Flow — not supported, removed in OAuth 2.1
  • Hybrid Flow with code token and code token id_token — not supported, removed in OAuth 2.1

ID token

  • JWT-signed ID token returned in the token response, signed with the tenant’s selected key (see RFC 7519)
  • iss, sub, aud, exp, iat standard claims
  • nonce claim — echoed from the authorization request
  • auth_time claim — time of authentication
  • acr claim — the achieved Authentication Context Class Reference, defined by the tenant
  • amr claim — Authentication Method References (RFC 8176)
  • sid claim — the session identifier used by logout
  • c_hash — code hash in the hybrid flow
  • at_hash — included whenever an access token is issued alongside the ID token
  • s_hash — included when the request carried state (see JARM)
  • Claims implied by scope (for example email for scope email) are not put in the ID token; they come from /userinfo, or from the claims parameter under id_token
  • Encrypted ID token (JWE) — not supported

UserInfo endpoint

  • GET and POST /userinfo, token in the Authorization header only (Bearer or DPoP)
  • JSON response, and a signed JWT response when the client sends Accept: application/jwt
  • sub always present
  • Scope-based claim release (openid, profile, email, address, phone)
  • claims parameter — a request that names only userinfo or only id_token, or a member with a null value, is accepted
  • First-party clients (those without a consent screen) are released the claims named in claims beyond the granted scope
  • Localized claims (name#fr, name#fr-CA) with fallback to the plain claim
  • Encrypted UserInfo response — not supported

Authorization request parameters

  • scope=openid — required to trigger OpenID Connect
  • nonce — replay protection for ID tokens; required when response_type includes id_token
  • max_age — a session older than the limit forces re-authentication; tokens carry over only if the same user signs in again
  • prompt — none, login and consent
  • prompt=select_account — accepted, with no behaviour of its own
  • acr_values — a voluntary request: values neither the tenant nor Versola defines are dropped, and acr reports what was achieved
  • login_hint — a hint; a value auth cannot use is ignored and does not fail the request
  • id_token_hint — identifies the user for re-authentication; an expired ID token is accepted
  • ui_locales — a hint; locales that are not configured are ignored
  • claims — explicit claim requests for userinfo and id_token
  • request — a signed request object passed by value (see RFC 9101; JarFlowSpec)
  • request_uri — a pushed authorization request reference from /par (see RFC 9126)
  • request_uri naming a client-hosted URL — not implemented; such a URL is refused and never fetched
  • display, registration — not implemented

Standard claims (§5.1)

  • sub — the user’s identifier
  • email and phone_number, the latter stored and compared in canonical E.164
  • Claims of the standard scopes (profile, email, address, phone) are seeded in the claim catalog, and any custom claim can be attached to a scope
  • Localized claim variants (claim#locale)
  • address — released as stored on the user when the scope is granted
  • email_verified, phone_number_verified and updated_at computed by the server — not computed; they are released only if the operator has stored them on the user
  • Pairwise subject identifiers — not implemented, although the default discovery document lists pairwise in subject_types_supported

Discovery

  • GET /.well-known/openid-configuration, with request_parameter_supported and request_uri_parameter_supported both true (see RFC 8414)

Session management and logout

  • OpenID Connect Session Management — not implemented
  • RP-Initiated, Front-Channel and Back-Channel Logout — see OIDC logout

Notes

  • acr_values, login_hint and ui_locales are hints by design, as the specification allows. acr_values can still fail when a defined value cannot be met for the known user.
  • Whether a deployment’s id_token_signing_alg_values_supported matches the key a tenant signs with depends on the stored discovery document; it is not derived from the key.

Where to look

The OpenAPI reference covers the authorize and userinfo specifications, and Security profiles explains which request rules depend on the tenant profile.