OAuth Resource Indicators for MCP: Complete Guide
Modern OAuth deployments often protect more than one resource server.
An organization might expose separate MCP servers for documentation, source code, issue tracking, cloud infrastructure, and internal APIs. If a single Access Token could be accepted by every service, the impact of a compromised token would be significantly greater.
OAuth Resource Indicators solve this problem by allowing clients to request an Access Token for a specific protected resource. The Authorization Server issues a token intended only for that resource server, and the resource server validates that the token was issued for it before granting access.
Within MCP, Resource Indicators help ensure that Access Tokens are bound to the correct remote MCP server, reducing the risk of token replay across multiple services.
Quick Answer
OAuth Resource Indicators allow clients to request an Access Token for a specific resource server. MCP servers validate that the token was issued for them before executing protected operations, preventing Access Tokens from being reused across unrelated services.
What Are OAuth Resource Indicators?
A Resource Indicator identifies the protected resource that an OAuth client wants to access.
Instead of requesting a generic Access Token, the client tells the Authorization Server which resource server requires authorization.
A simplified flow looks like this:
OAuth Client
│
Request Resource
docs.example.com
│
▼
Authorization Server
│
Issue Token
│
▼
Access Token
The resulting Access Token is intended for that specific resource rather than every protected service managed by the Authorization Server.
Why MCP Uses Resource Indicators
Many organizations deploy multiple remote MCP servers.
For example:
Documentation MCP
Git MCP
Issue Tracker MCP
Infrastructure MCP
Each server protects different resources.
Without Resource Indicators, a single Access Token might accidentally become valid across multiple services.
Instead, the Authorization Server issues separate Access Tokens that are bound to individual MCP servers.
This reduces risk while improving authorization boundaries.
How Resource Indicators Work
The client specifies the resource it wants to access when requesting authorization.
OAuth Client
│
Resource:
https://docs.example.com
│
▼
Authorization Server
│
Issue Token
│
▼
Access Token
Later, the client presents that Access Token only to the corresponding MCP server.
OAuth Client
│
Bearer Token
│
▼
Documentation MCP
│
Validate Resource
│
▼
Execute Tool
If the token is presented to a different MCP server, the request should be rejected.
One Authorization Server, Many MCP Servers
Resource Indicators become especially useful when several MCP servers share the same Authorization Server.
A simplified architecture might look like this:
Authorization Server
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
Documentation MCP Git MCP Infrastructure MCP
Each MCP server represents a different protected resource.
Although they trust the same Authorization Server, they should not automatically trust every Access Token that the server issues.
Instead, each server validates that the token was issued specifically for its own resource.
Resource Indicators vs OAuth Scopes
Resource Indicators and OAuth Scopes are closely related, but they solve different problems.
A Resource Indicator identifies where an Access Token may be used.
A Scope identifies what the application is allowed to do once it reaches that resource.
| Resource Indicator | OAuth Scope |
|---|---|
| Identifies the resource server | Identifies requested capabilities |
| Determines where a token is valid | Determines what the token can do |
| Bound to an MCP server | Bound to permissions |
| Limits token audience | Limits token privileges |
For example:
Resource:
https://docs.example.com
Scopes:
docs:read
docs:write
In this case:
- the Resource Indicator specifies that the token is intended for the documentation MCP server
- the scopes specify which documentation operations are permitted
Together, Resource Indicators and Scopes provide fine-grained authorization while minimizing unnecessary access.
Resource Indicators and Audience Validation
Resource Indicators are closely related to the OAuth concept of audience.
When an Authorization Server issues an Access Token for a particular resource, that relationship is commonly reflected through the token's audience.
A simplified validation process looks like this:
Access Token
Audience:
docs.example.com
│
▼
Documentation MCP ✔
Git MCP ✘
Before executing a protected operation, the MCP server validates that the Access Token was intended for its own resource.
This prevents Access Tokens issued for one service from being accepted by another.
Multiple Resource Servers
Organizations frequently deploy several protected services behind a single Authorization Server.
For example:
OAuth Client
│
▼
Authorization Server
│
┌────┼────┬────┐
▼ ▼ ▼ ▼
Docs Git Issues Cloud
Each resource receives its own Access Token or validates that an existing token was issued specifically for that resource.
This separation reduces the blast radius if a token is compromised.
Rather than exposing every protected service, the leaked token remains usable only against its intended resource.
What Happens if the Wrong Resource Is Used?
Suppose an application requests an Access Token for the documentation MCP server but later attempts to use that token with the Git MCP server.
Access Token
Resource:
Documentation MCP
│
▼
Git MCP
│
▼
Reject Request
Although the Access Token may still be valid, it was not issued for the Git MCP server.
The server should therefore reject the request rather than executing protected operations.
This behavior significantly improves security in environments where many MCP servers share the same Authorization Server.
Common Errors
Most Resource Indicator problems occur when the requested resource and the receiving resource do not match.
Invalid Resource
The client requests authorization for a resource that the Authorization Server does not recognize.
Possible causes include:
- incorrect resource identifier
- unsupported MCP server
- malformed resource URI
The Authorization Server rejects the request before issuing an Access Token.
Wrong Resource Server
An Access Token is presented to a different MCP server than the one for which it was issued.
Token
Audience = Docs
Used With:
Git Server
✘ Rejected
Even though the Access Token may be cryptographically valid, it should not authorize access to unrelated resources.
Audience Validation Failure
During token validation, the MCP server determines that the Access Token's audience does not match its own identity.
Requests failing audience validation should not proceed to authorization checks or tool execution.
Security Best Practices
Resource Indicators are most effective when combined with other OAuth security mechanisms.
Request Tokens for Specific Resources
Applications should request Access Tokens only for the MCP server they intend to access.
Avoid requesting overly broad or generic resource identifiers.
Validate the Audience
Every MCP server should verify that incoming Access Tokens were issued specifically for that server before processing requests.
Combine Resource Indicators with OAuth Scopes
Resource Indicators define where an Access Token may be used.
Scopes define what the client may do there.
Using both mechanisms together provides stronger authorization boundaries than either mechanism alone.
Issue Short-Lived Access Tokens
Binding Access Tokens to specific resources already limits their usefulness.
Short expiration times further reduce the impact of accidental exposure.
Want to analyze your API security?
Import your OpenAPI spec and generate a Security Report automatically.
Conclusion
OAuth Resource Indicators help Authorization Servers issue Access Tokens that are valid only for specific protected resources.
In MCP deployments, this ensures that an Access Token issued for one remote MCP server cannot automatically be reused with another server managed by the same Authorization Server.
Combined with Access Tokens, OAuth Scopes, audience validation, and the principle of least privilege, Resource Indicators provide an important layer of defense for modern multi-server MCP environments.
Continue learning:
- OAuth Access Tokens for MCP — Learn how Access Tokens authenticate requests.
- OAuth Scopes for MCP — Understand how OAuth limits application permissions.
- OAuth Authorization Code for MCP — Explore delegated user authentication.
- OAuth Client Credentials for MCP — Learn how machine-to-machine OAuth works.
- OAuth PKCE for MCP — Protect Authorization Code flows against interception.
- MCP OAuth — Understand the complete OAuth authorization model used by remote MCP servers.