Limit disclosure and authenticate the endpoint
06Token metadata may identify people and reveal other services. The authorization server can tailor the response to the protected resource and avoid unnecessary disclosures.
The resource server validates the intended authorization-server endpoint and its certificate before sending token information. The failing example delivers no token to the wrong endpoint.
Source for this drawing: RFC 7662 · Read RFC section 5 ↗
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
- Pairwise identifier
- A service-specific opaque subject string that can differ across resources.
- Data minimization
- Returning only information needed by the intended recipient.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Responses MAY differ between protected resources, including limiting disclosed scopes. Privacy-sensitive information MUST be protected against disclosure to unintended parties.
- Responses MAY differ between protected resources, including limiting disclosed scopes. Privacy-sensitive information MUST be protected against disclosure to unintended parties.
- Omitting sensitive information is the simplest minimization method. Opaque service-specific subject identifiers can differ between resources; a global username is not required.
- The endpoint MUST authenticate protected-resource callers and SHOULD specifically authorize them to call it. The server MUST support TLS1.2; certificate checking by the client or resource is a MUST when using TLS.
- Credentials and inspected tokens must be protected. The server MAY disallow HTTP GET to avoid token values in query logs; the defined request flow uses POST. Extra context extensions have their own privacy implications.
Fictional subject values resource-A-7 and resource-B-9 illustrate one privacy technique, not a required derivation algorithm or two real people. Discovery is outside this RFC; configure a trustworthy endpoint and validate its certificate. TLS1.0/1.1 are not authorized by this guide. No real token, user identity or client IP address is used in these examples. Privacy filtering does not remove the authorization server’s responsibility to perform applicable state checks.
Read the RFC section ↗