Visual RFC.
ALL RFCs / RFC 8414
Read the RFC ↗
RFC 8414 / Authorization server metadata

Read a metadata response as configuration

02

A successful response is a JSON object. Its fields describe roles and capabilities; they are not a token response or an access grant.

RFC 8414 · § 3.2EXAMPLE
4 / 4
Read a metadata response as configurationEmpty UI-language list is removed before publication, as required for zero-element claims. The remaining illustrative metadata keeps required nonempty response types; language support is unspecified.Omit a zero-element claimZero-element claim MUST be omittedRequired fields, conditions and optional claims differ
04
Omit a zero-element claim

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 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

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.
DETAILS

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 ↗

All chapters in RFC 8414

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗