RFC 8707 / START HERE
OAuth resource indicators, before the details
Resource Indicators for OAuth 2.0 is the publication’s name. A resource indicator identifies the service a client intends to access; OAuth is the authorization framework it extends.
A client is an app asking an authorization server for a token. The resource server is the API that will receive that token. The resource parameter tells the authorization server where the token is intended to be used; scope separately says what access is requested.
The idea in one picture
Client: intended API
Server: token policy
API: checks audience
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
One authorization server may serve many APIs. It needs the target identity to choose token content and audience restrictions: which services may accept the token. RFC 8707 adds this signaling mechanism without replacing OAuth or defining a new token format.
A familiar example
A picnic app gets permission for a calendar and a contacts service. It can ask for one calendar token, then later request a contacts token under its original grant. Naming a resource does not itself grant access, validate an endpoint or make a stolen bearer token harmless.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Name the intended resourceA resource indicator names the service where a client intends to use an access token. Scope separately describes the requested permissions.→
- Authorize a set of resourcesIn the code flow, resource indicators apply to the full authorization grant. A later token request can select a smaller audience under server policy.→
- Select an audience at the token endpointA client can request a calendar token from a two-resource grant, then use the refresh token to request a contacts token under server policy.→
- Separate permissions from destinationsRequesting two scopes for two resources asks for each scope at each resource. It does not describe a different private scope list for each destination.→
- Enforce audiences and tenant boundariesAudience 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.→
This introduction explains RFC 8707 (2020). Read the original RFC ↗