Preserve TLS, key and resource boundaries
06Correctly shaped metadata can still be unsafe if the connection, issuer, keys or resource association are wrong.
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 ↗
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.
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.
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 ↗