RFC 8414 — Authorization Server Metadata — Versola Docs
/docs
Pre-1.00.7.5versola.ioGitHub
RUEN

RFC 8414 — Authorization Server Metadata

OAuth 2.0 Authorization Server Metadata and OpenID Connect Discovery — the endpoints, fields and which of them Versola derives.

Specification: RFC 8414, OpenID Connect Discovery 1.0

Authorization Server Metadata lets a client discover the server’s endpoints and capabilities without manual configuration.

Status

Implemented. Checked claims: 27 of 31.

Endpoints

  • GET /.well-known/oauth-authorization-server
  • GET /.well-known/openid-configuration (OpenID Connect alias)

Both return the same JSON document, and no authentication is required (DiscoveryAndJwksSpec).

Default document

A deployment starts from a stored document that the operator can edit. The one generated for a new installation looks like this:

{
  "issuer": "https://id.example.com",
  "authorization_endpoint": "https://id.example.com/authorize",
  "token_endpoint": "https://id.example.com/token",
  "userinfo_endpoint": "https://id.example.com/userinfo",
  "jwks_uri": "https://id.example.com/.well-known/jwks.json",
  "introspection_endpoint": "https://id.example.com/introspect",
  "revocation_endpoint": "https://id.example.com/revoke",
  "pushed_authorization_request_endpoint": "https://id.example.com/par",
  "end_session_endpoint": "https://id.example.com/logout",
  "scopes_supported": ["openid", "profile", "email", "address", "phone", "offline_access"],
  "response_types_supported": ["code", "code id_token"],
  "response_modes_supported": ["query", "fragment", "jwt", "query.jwt", "fragment.jwt"],
  "code_challenge_methods_supported": ["S256"],
  "grant_types_supported": ["authorization_code", "client_credentials", "refresh_token"],
  "subject_types_supported": ["public", "pairwise"],
  "id_token_signing_alg_values_supported": ["ES256"],
  "token_endpoint_auth_methods_supported": ["client_secret_basic", "client_secret_post", "private_key_jwt"],
  "token_endpoint_auth_signing_alg_values_supported": ["ES256", "PS256"],
  "dpop_signing_alg_values_supported": ["ES256", "PS256"],
  "request_object_signing_alg_values_supported": ["ES256", "PS256"],
  "claims_supported": ["sub", "iss", "aud", "exp", "iat", "jti", "nonce", "auth_time", "acr", "amr", "sid"],
  "frontchannel_logout_supported": true,
  "frontchannel_logout_session_supported": true,
  "backchannel_logout_supported": true,
  "backchannel_logout_session_supported": true,
  "authorization_response_iss_parameter_supported": true
}

On top of the stored document, auth adds or overwrites the fields below when it serves it.

Derived fields

  • request_parameter_supported — always true
  • request_uri_parameter_supported — always true; a request_uri here names a pushed authorization request, and a client-hosted URL is refused (see RFC 9101)
  • dpop_signing_alg_values_supported, token_endpoint_auth_signing_alg_values_supported and request_object_signing_alg_values_supported — normalised to the algorithms auth has verifiers for, and the same sets the checks use
  • token_endpoint_auth_methods_supported — private_key_jwt is always added to what is stored
  • authorization_signing_alg_values_supported — the algorithms of the keys the deployment publishes (see JARM)
  • mtls_endpoint_aliases — present only when the mutual TLS listener is configured (see RFC 8705)

Implemented metadata fields

Required:

  • issuer
  • authorization_endpoint
  • token_endpoint

Recommended:

  • jwks_uri
  • response_types_supported — code and code id_token
  • grant_types_supported
  • token_endpoint_auth_methods_supported
  • revocation_endpoint
  • introspection_endpoint
  • scopes_supported
  • code_challenge_methods_supported — ["S256"]
  • pushed_authorization_request_endpoint (RFC 9126)
  • response_modes_supported

OpenID Connect extensions:

  • userinfo_endpoint
  • id_token_signing_alg_values_supported
  • claims_supported
  • subject_types_supported
  • end_session_endpoint, frontchannel_logout_supported, backchannel_logout_supported (OIDC logout)
  • authorization_response_iss_parameter_supported (RFC 9207)

Not published:

  • require_pushed_authorization_requests — requirement is per client, not per deployment
  • acr_values_supported — not in the generated document
  • tls_client_certificate_bound_access_tokens — an operator-set field of the stored document, not derived
  • signed_metadata — not implemented

Notes

  • A deployment generated by versola-cli stores ["ES256"] in id_token_signing_alg_values_supported; a deployment created earlier keeps the value it stored (["PS256"] before this change).
  • Stored fields are served as written. id_token_signing_alg_values_supported is not checked against the keys tenants sign with, and the generated subject_types_supported lists pairwise although only public subject identifiers are issued.
  • The document is served once for the whole deployment. Per-tenant differences, such as mutual TLS support behind a tenant’s proxy, are not reflected in it.

Where to look

The OpenAPI reference has the metadata specification.