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

Apply defaults without inventing capabilities

03

Some omitted lists have specified defaults; others deliberately have no default. An advertised feature is still separate from client policy.

RFC 8414 · § 2EXAMPLE
4 / 4
Apply defaults without inventing capabilitiesExplicit S256 advertisement is separate from client credentials, successful PKCE and deployment security policy. Omission has the no-PKCE meaning stated by the publication; no silent bypass is authorized.Interpret omission according to the named fieldSelected metadata rulesAdvertisement is not a completed exchangeSelected publication defaults · client eligibility is separate
04
Keep PKCE advertisement and policy separate

The illustrative metadata explicitly advertises S256. Omission in §2 means no PKCE support; it is not a successful exchange or permission to bypass a client’s security requirements.

Source for this drawing: RFC 8414 · Read RFC section 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

Omission does not always mean the same thing.

  • If response_modes_supported is omitted, §2 defaults to query and fragment. If grant_types_supported is omitted, its default is authorization_code and implicit. These are the published metadata interpretation defaults; they do not override later OAuth security guidance or recommend deploying every listed grant.
  • The omitted token_endpoint_auth_methods_supported default is client_secret_basic. The revocation endpoint has the same omitted-method default. Introspection is different: if its authentication-method list is omitted, supported methods MUST be determined by other means. Do not copy the token default into introspection (§2).
  • For token, revocation or introspection endpoint authentication, if private_key_jwt or client_secret_jwt is specified, the corresponding signing-algorithm metadata entry MUST be present. No default algorithms are implied by an omitted entry, and none MUST NOT be used. The token-endpoint list additionally says servers SHOULD support RS256 (§2).
  • These algorithms are for JWTs used to authenticate a client at the relevant endpoint. They are not an access-token format declaration or algorithms for signed_metadata. Metadata support is separate from an actual client credential, successful signature or authorization decision.
  • code_challenge_methods_supported is OPTIONAL. In this publication, omission means the server does not support PKCE; if present, it lists supported methods such as S256. Proof Key for Code Exchange (PKCE) binds an authorization-code exchange to a fresh verifier kept by the client. Metadata absence does not instruct a client to bypass its security policy or silently downgrade. The OAuth security BCP remains separate guidance (§2; companion RFC9700).
  • Advertised scopes may be incomplete; an advertised grant, response type or authentication method does not mean every registered client may use it. Client registration, eligibility, authorization and current deployment security are outside these default calculations.
DETAILS

The helper calculates a selected set of publication defaults and algorithm-presence checks. It is not a complete metadata validator, client registration policy or cryptographic verifier.

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 ↗