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

Preserve TLS, key and resource boundaries

06

Correctly shaped metadata can still be unsafe if the connection, issuer, keys or resource association are wrong.

RFC 8414 · § 6.1EXAMPLE
4 / 4
Preserve TLS, key and resource boundariesAn illustrative application policy blocks an unrelated protected resource. RFC8414 assumes appropriate resource determination by other means and does not automatically provide this check.Resource association needs separate application knowledgeOAuth clientUnrelated resourceIllustrative application association checkNo live TLS, keys, grants or resource requests are tested
04
Choose the right protected resource separately

A client must have its own means of choosing an appropriate resource. The illustrative application gate stops an unrelated destination; RFC8414 does not determine this association automatically.

Source for this drawing: RFC 8414 · Read RFC section 6.1 ↗

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

Configuration discovery is not a complete trust or authorization system.

  • Implementations MUST support TLS. The publication requires authorization servers to support TLS 1.2 and MAY support additional suitable TLS mechanisms; this is not a recommendation to avoid newer TLS. Clients MUST check server certificates as specified, and TLS confidentiality and integrity protection MUST be applied. Consult current BCP195 deployment guidance (§6.1).
  • When requesting metadata, the client MUST check the certificate for the issuer URL. A forged metadata response can substitute an attacker’s keys and endpoints. A separate MUST exact issuer check prevents use of data about a different issuer; a valid HTTPS connection alone does not replace it (§6.2).
  • Optional jwks_uri MUST use HTTPS. Its JWK Set has signing keys used to validate server signatures and MAY also include encryption keys. When both signing and encryption keys are published, a use parameter is REQUIRED on all keys in that JWK Set to identify intended use. A key identifier or downloaded key is not authorization by itself (§2).
  • Standard publication makes configuration easier for legitimate clients and attackers alike; the same defenses still apply (§6.3). Metadata does not automatically prove a server is trustworthy, secure a client registration, protect an embedded secret or approve a grant.
  • Securely determining which protected resources are appropriate for an authorization server is outside this specification. The client is assumed to have a means of choosing them correctly. Using an inappropriate resource can let an attacker proxy to a valid service without the client or server detecting it. The final gate is an illustrative application policy check, not an automatic RFC 8414 guarantee (§6.4).
  • Extensions and identifiers are registered under §7, including cross-registry uniqueness rules for introspection authentication methods. Registration is a naming/interoperability mechanism, not a security review or permission to follow arbitrary URLs.
DETAILS

No TLS handshake, key generation, signature verification, resource request or real OAuth service is exercised. Gates mark the failed check or assumed application policy explicitly.

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 ↗