Scopes define what actions a token may perform, while resource indicators define where that token may be used. Both are needed in MCP because narrow permissions do not prevent a token from being accepted by the wrong server if the audience is not explicitly bound.
How Scopes and Resource Indicators Divide Permission from Audience
Scopes and resource indicators solve different problems in OAuth. Scopes answer what a token can do, such as reading mail or writing files. Resource indicators answer where that token is meant to work, so the authorization server can issue an access token for a specific protected resource instead of a generic one that is accepted too broadly.
That distinction matters because a token can be narrowly scoped and still be misused if the recipient server is not explicitly identified. In other words, scope limits capability, while the resource binding limits audience. When you are evaluating token design, treat them as complementary controls rather than substitutes.
For the protocol background, see RFC 6749: The OAuth 2.0 Authorization Framework and RFC 8707: Resource Indicators for OAuth 2.0.
Why Resource Binding Matters in MCP and Other Multi-Server Flows
This difference becomes operationally important in MCP because an MCP client may talk to more than one server, and the wrong server can become an unintended token recipient if audience binding is vague. Scopes alone do not stop that failure mode. A token with the right scope can still be replayed against the wrong endpoint if the resource server is not the one the client and authorization server agreed on.
MCP’s authorization model therefore needs both the permission model and the audience model to line up. That is why resource indicators, protected resource metadata, and correct server-side validation belong in the same design conversation as scopes. The practical question is not just “what should this token do?” but also “which server is allowed to accept it?”
For the MCP-specific implementation pattern, see the MCP Security Guide and the IETF material on RFC 9728: OAuth 2.0 Protected Resource Metadata.
For token replay and sender-constraining context, current OAuth security guidance also benefits from audience binding and narrower token reuse boundaries, as reflected in RFC 9700: Best Current Practice for OAuth 2.0 Security.
When to Use Scopes, Resource Indicators, or Both
Use scopes when you need to express delegated authority, and use resource indicators when you need to bind that authority to a specific API or server. If a client only needs one server, audience binding may feel implicit, but it should still be explicit in any environment where tokens can cross trust boundaries. If a flow involves multiple protected resources, the absence of a resource indicator is a design gap, not just a convenience trade-off.
In practice, both controls should be reviewed together during token issuance and acceptance. Scopes should be as narrow as the task permits, and the resource server should reject tokens that were minted for a different audience even when the scope string looks valid. That keeps the authorization server, client, and resource server aligned on both privilege and destination.
For broader OAuth and token design guidance, see RFC 6749, RFC 8707, and OpenID Connect Core 1.0.
Risk and Threat Considerations
The main risk is over-acceptance: a token that was meant for one resource can be replayed at another if audience binding is missing or weak. That creates a confused-deputy style failure where the server trusts a valid token without checking whether it was intended for that server.
Failure mechanism: The authorization server issues a token with valid scopes but no sufficiently specific resource indicator, and the resource server accepts it because it only checks signature or scope, not intended audience.
Impact: Attackers or misrouted clients can use a legitimate token outside its intended boundary, turning a least-privilege design into broader cross-resource access and increasing the blast radius of token theft or client misconfiguration.
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 |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | OAuth tokens for MCP resource servers depend on service-to-service authentication and audience validation. |
| AC-3 — Access Enforcement | Scopes and resource indicators together enforce what a token may do and where it may be used. | |
| Recommendation — Bind tokens to the intended resource server and reject tokens presented to the wrong audience. Enforce both privilege scope and resource audience before granting access. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Missing audience binding can let valid tokens authenticate to the wrong API or server. |
| API5 — Broken Function Level Authorization | Scopes express allowed actions, which maps directly to function-level authorization. | |
| API8 — Security Misconfiguration | Improper token audience handling is a deployment and validation misconfiguration risk. | |
| Recommendation — Validate token audience as part of authentication before accepting API requests. Map scopes to functions and deny calls outside the token's permitted actions. Configure resource servers to require correct audience metadata and reject generic tokens. | ||
Practitioner Guidance
What to verify: Confirm that every access token is checked for both scope and intended resource, and that resource servers reject tokens minted for a different audience even when the scope matches. In multi-server MCP deployments, test this with negative cases, not just happy-path authorizations.
Decision rule: If the token can reach more than one protected resource, treat audience binding as mandatory, not optional. If the flow is single-resource today but likely to expand later, design the resource indicator path now rather than retrofitting it after clients have already learned to accept generic tokens.
Practitioner takeaway: Scopes limit what a token can do, but resource indicators decide where that token is allowed to matter, and both checks must hold if you want narrow permissions to stay narrow in practice.
Related resources from NHI Mgmt Group
- What is the difference between OAuth scopes and OAuth RAR?
- Why do MCP environments need resource indicators if OAuth scopes already exist?
- What is the difference between OAuth scopes and roles in agentic access models?
- What is the difference between OAuth authorization server metadata and protected resource metadata?