Resource Indicators for OAuth 2.0 is an extension to OAuth 2.0 that lets a client name the specific protected resource or API it wants a token for. The resource indicator helps the authorisation server issue a token with the right audience and scope, reducing token confusion across different APIs.
How Resource Indicators Change OAuth 2.0 Token Issuance
Resource Indicators for OAuth 2.0 add a way for the client to say which protected resource it is trying to reach, so the authorization server can issue a token aimed at that resource rather than a broader, ambiguous one. That small addition matters because token audience is part of the security boundary.
Without a resource indicator, a client may end up with a token that is valid in more places than intended, especially in environments where one authorization server serves multiple APIs. With a resource indicator, the token request carries clearer intent and reduces audience confusion across resource servers.
For the underlying standard, see RFC 8707: Resource Indicators for OAuth 2.0, which defines the mechanism that lets clients name the target resource so access tokens are audience-restricted.
Why Resource Indicators Exist in Real Deployments
In modern OAuth deployments, the authorization server, client, and resource server are often separate systems, and a single client may call more than one API. Resource indicators help the issuer distinguish which API is the intended recipient, which reduces accidental reuse of the same access token across unrelated services.
This is especially important when scopes alone do not fully express the target system. Scope names can describe actions, but resource indicators help bind the token to a specific audience, which is what prevents one valid token from being accepted by the wrong API.
The pattern is easy to miss because the client is still “doing OAuth correctly” in a broad sense. The security improvement comes from making the target resource explicit, not from changing the grant itself.
For the base protocol context, RFC 6749: The OAuth 2.0 Authorization Framework remains the starting point for understanding how clients obtain access tokens in the first place.
Where Resource Indicators Fit With Scopes, Audience, and API Boundaries
Resource indicators do not replace scopes, they complement them. Scopes still express what the token can do, while the resource parameter helps express where the token is meant to work. In practice, that separation makes authorization decisions easier to reason about and reduces the chance of a token being accepted outside its intended trust boundary.
That distinction is especially useful in shared authorization server setups, API gateways, and platform environments where many services rely on the same identity provider. A well-designed token should answer both questions: “what can it do?” and “for which resource was it issued?”
When teams design OAuth scope models, they should treat resource indicators as part of the audience-binding story, not as a substitute for good scope design. The two controls solve different problems, and both are needed when multiple APIs share a common token issuer.
See also OAuth Scope Design Guide for the related question of how scope granularity and audience binding work together in practice.
Operational Implications for API Security and Token Handling
Resource indicators become most valuable when organisations operate many APIs, especially when some are sensitive, high privilege, or externally reachable. They support tighter token audience control, clearer service ownership, and better separation between APIs that should not share authorization context.
That also means implementation mistakes are more visible. If the resource value is ignored, loosely validated, or mapped to the wrong backend, the organisation can still end up with audience confusion, broken authorization assumptions, or token replay against a different API than the one that issued the request.
A sound implementation therefore needs the authorization server and the resource server to agree on what the intended audience means. The business value is not just cleaner requests, but fewer opportunities for a token to be accepted by the wrong service.
For a broader implementation reference, OAuth 2.0 and OpenID Connect Guide for Identity Teams gives the surrounding OAuth context, while the MCP authorisation guide shows how resource indicators are used in a more specific protocol profile: MCP Authorisation Specification Guide.
Risk and Threat Considerations
Resource indicators reduce token confusion, but they only help when the authorization server and resource server actually enforce audience binding. If a token can be replayed across APIs, or if a client can obtain a token for one resource and use it at another, the organisation can inherit cross-API authorization failure and unintended access.
Failure mechanism: The resource is omitted, mis-validated, or treated as advisory, so the resulting token is accepted by a different API than the one the client intended, creating confused-deputy style access and audience mismatch.
Impact: A misplaced audience boundary can expose data or actions in the wrong API, weaken least-privilege assumptions, and make token theft more valuable because the stolen token has broader practical reach than intended.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Audience confusion can weaken API token validation and acceptance boundaries. |
| Recommendation — Enforce strict token audience checks so an access token is only accepted by its intended API. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Resource-specific token handling depends on secure issuance and lifecycle handling of OAuth tokens. |
| AC-6 — Least Privilege | Audience-bound tokens support least-privilege access by limiting where a token can be used. | |
| Recommendation — Manage OAuth token issuance and rotation so tokens remain bounded to the intended resource and use case. Limit token scope and audience so each credential works only for the minimum required API. | ||
Practitioner Guidance
Why practitioners should care: Resource indicators are a simple control point with outsized effect in multi-API environments, because they make token intent machine-readable and easier to enforce consistently. Teams should treat them as part of the access boundary, not a cosmetic request parameter.
What to watch for: The highest-value implementation checks are whether the authorization server issues resource-specific tokens, whether the resource server verifies audience strictly, and whether clients ever fall back to generic tokens when a target API is known.
Practitioner takeaway: Use resource indicators wherever one authorization server serves more than one protected API, and verify that every hop preserves the same audience assumption.