RFC 8707 Resource Indicators is an OAuth 2.0 extension that lets a client tell the authorisation server which protected resource it wants a token for. The resource value helps the server issue an access token with audience scoping so the token is not accepted by the wrong API.
What Resource Indicators Actually Do in OAuth
RFC 8707 adds a way for a client to name the protected resource it wants a token for, so the authorisation server can issue an access token with a clearer audience. That reduces the chance that a valid token is accepted by the wrong API.
At a practical level, this is about binding the token request to the intended resource server rather than treating the token as broadly usable across multiple APIs. The result is narrower token scope, better audience control, and fewer opportunities for confused-deputy style misuse.
Why Audience Scoping Matters
Without an explicit resource indicator, the authorisation server may have less context about which API the client actually intends to call. In ecosystems with multiple APIs, gateways, or shared authorisation servers, that ambiguity can lead to tokens being accepted in places they were never meant to reach.
Audience scoping matters because access tokens are security objects, not just session artefacts. If the wrong API accepts a token, the blast radius of a compromise grows, and the defender loses one of the simplest forms of token containment.
How It Relates to OAuth and API Boundaries
RFC 8707 fits into the broader OAuth pattern of making access decisions more specific at issuance time. It complements resource server metadata, scope design, and token validation rules by making the target service explicit earlier in the flow.
That matters in distributed platforms where one identity provider serves many APIs. A resource indicator can help separate trust boundaries so that each API validates tokens against the audience it actually owns, rather than relying on a generic token that might work too widely.
This is especially useful where clients talk to multiple protected resources in the same ecosystem. The same OAuth machinery can support different APIs, but the token should still be shaped for the exact resource the client is about to call.
What Practitioners Should Verify
Implementers should confirm that the authorisation server, client, and resource server all agree on how the resource value is interpreted and enforced. If one side treats it as advisory and another treats it as binding, the control loses most of its security value.
Practitioners should also check that token validation actually enforces audience expectations at the API edge. If the resource indicator is present during issuance but ignored during validation, the deployment still has a token containment gap.
In mature environments, this is less about adding a new concept and more about making existing OAuth boundaries explicit. That makes it easier to reason about token placement, API ownership, and where an access token should and should not be accepted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Resource indicators narrow token audience so APIs only accept tokens meant for them. |
| Recommendation — Enforce audience checks so each API rejects tokens not issued for its resource. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | RFC 8707 affects how access tokens are issued, scoped, and handled as authenticators. |
| IA-9 — Service Identification and Authentication | Resource-scoped OAuth tokens help services authenticate requests for the correct protected resource. | |
| Recommendation — Bind token issuance and validation to the intended audience and rotate or revoke tokens cleanly. Require service-to-service tokens to carry and verify the correct audience. | ||
| OWASP ASVS | V10 — OAuth and OIDC | The term is an OAuth extension that strengthens authorization server and token audience handling. |
| V8 — Authorization | Audience scoping supports correct authorization boundaries between protected resources. | |
| Recommendation — Verify OAuth deployments enforce audience-bound token issuance and resource-specific acceptance. Validate that each protected resource authorizes only tokens intended for it. | ||