Enforce audiences and tenant boundaries
05Audience restriction works only when each recipient checks that a token was meant for it. Multi-audience bearer tokens enlarge the set of services that can reuse them.
Separate case: urn:example:calendar is mapped to a configured endpoint. An unvalidated endpoint receives no token; an abstract name is not a safe locator by itself.
Source for this drawing: RFC 8707 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A key is different from permission.
An app, a person, and a server have different roles. Follow who asks, who grants permission, and who checks the credential. A key in the drawing is an analogy, not a literal protocol field.
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.
Current OAuth security BCP makes recipient-side audience enforcement explicit: a resource server MUST refuse a request whose token was not meant for it. This is related guidance, not a formal update or a new edition of RFC8707.
Read the updated RFC section ↗Check audience and action before serving a request.
- Use a specific resource URI including the tenant-identifying portion where applicable. A token for the blue tenant must not accidentally authorize access to another tenant hosted at the same origin.
- Using one resource per token request is encouraged. A multi-audience bearer token is usable at each intended recipient, so any recipient can potentially reuse it at the others; high mutual trust is needed. The server may refuse such a request.
- RFC9700 §2.3 says access tokens SHOULD be audience-restricted to a specific resource server, or a small set if necessary, and a resource server MUST refuse a request whose token was not meant for it. Audience checks complement signature/introspection, expiry, action and authorization checks.
Every acceptance in this drawing assumes all other token and policy checks pass. Abstract resource IDs require validating the network endpoint out of band; accepting an identifier is not automatic discovery or fetch permission. Resource indicators can let the authorization server observe more granular resource-use intentions (RFC8707 §4); they do not add confidentiality.
Read the RFC section ↗