Read a metadata response as configuration
02A successful response is a JSON object. Its fields describe roles and capabilities; they are not a token response or an access grant.
A zero-element language array is not sent. If omitted, supported UI languages are unspecified. Preserve a nonempty response_types_supported in this illustrative document.
Source for this drawing: RFC 8414 · Read RFC section 3.2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Required, conditional and optional fields have different meanings.
- A successful response MUST have HTTP 200 OK and application/json with a JSON object containing metadata claims. Multi-value claims use arrays, and claims with zero elements MUST be omitted. Other claims MAY be returned. Errors use the applicable HTTP status; a successful transport status alone does not validate the issuer (§§3.2–3.3).
- issuer and response_types_supported are REQUIRED by the published §2 text. authorization_endpoint is REQUIRED unless no supported grant types use that endpoint. token_endpoint is REQUIRED unless only implicit is supported. These are publication requirements, not advice to enable the implicit grant in a current deployment.
- authorization_endpoint is for browser authorization; token_endpoint is for token requests. Optional jwks_uri points to a JWK Set document with signature-validation keys and MUST use HTTPS. registration_endpoint, revocation_endpoint and introspection_endpoint describe other operations when present. An endpoint URL is not itself a credential or permission (§2).
- scopes_supported is RECOMMENDED, but servers MAY omit some supported scopes even when publishing the list. Optional documentation, policy and terms URLs help registration and developers; the registration process SHOULD display supplied policy/terms URLs. Optional UI language lists describe supported languages; omission leaves the set unspecified (§2).
- Reported, unverified technical erratum7793 proposes changing the response_types_supported requirement for servers with no authorization-endpoint grants. This guide retains the published REQUIRED wording and does not claim that report is accepted. The conditional-endpoint pictures are selected rules, not complete client-credentials-only metadata documents.
- Reported, unverified erratum9178 concerns different issuer names in the separate request/response examples. This guide uses internally consistent fictional examples and applies §3.3’s exact check. Rejected editorial erratum8696 does not rewrite the historical reference list. Additional metadata names are registered under §7; an extension’s presence does not grant a client automatic support for it.
Sheets show selected fields, not a full server schema or deployment configuration. New metadata does not perform login, client registration or a token exchange.
Read the RFC section ↗