Resource indicators in OAuth 2.0 tighten MCP token boundaries

At a glance

What this is: This guide explains how RFC 8707 binds OAuth tokens to a specific resource server and why that audience check matters for secure MCP authorization.

Why it matters: It matters because IAM, NHI, and agentic AI programmes all fail when one token can roam across resources, weakening least privilege and increasing replay risk.

👉 Read WorkOS's guide to RFC 8707 and secure MCP authorization

Context

OAuth access tokens are often treated as broadly usable unless the authorization flow explicitly narrows their audience. That creates a confused deputy problem in multi-resource environments, where the same token can be replayed against a different API than the one it was meant for. For IAM and NHI teams, this is an authorization boundary problem, not just a protocol detail.

In MCP deployments, that boundary becomes more important because AI agents may request tokens across multiple resource servers in a single session. RFC 8707 gives the authorization server a standard way to bind issuance to a declared resource URI, but the control only works if the resource server also checks the audience claim on receipt. The failure mode is familiar: intended scope at issuance, overbroad access at use time.

Key questions

Q: How should security teams handle OAuth tokens in multi-resource environments?

A: Security teams should bind OAuth tokens to a specific resource server and enforce audience validation at the point of use. That means the authorization server issues a token for one declared URI, the resource server rejects mismatched audiences, and client caches stay partitioned by resource. Without both controls, least privilege breaks down across APIs.

Q: Why do audience-bound tokens matter for MCP authorization?

A: MCP clients can move across multiple resource servers in a single session, so generic tokens create replay risk and scope ambiguity. Audience-bound tokens reduce that risk by tying each token to one resource URI. This gives teams a clearer boundary for authorization, logging, and incident response when agents or integrations are active.

Q: What do IAM teams get wrong about OAuth resource indicators?

A: Teams often assume that correct token issuance is enough. In practice, resource indicators only help if the receiving API validates the token audience and if client-side caching does not blur token reuse across resources. Issuance without enforcement is partial control, not complete authorization.

Q: How can organisations prevent confused deputy problems in API access?

A: Organisations should make resource identity explicit everywhere a token is issued or consumed. Use resource-specific scopes, validate the aud claim, and avoid shared token pools across unrelated services. That combination limits unintended cross-API access and makes misuse easier to detect.

Technical breakdown

Resource indicators and audience-bound tokens

RFC 8707 adds a resource parameter to OAuth requests so the client declares which resource server the token is for before issuance. The authorization server can then set the token's audience, often through the JWT aud claim, and filter scopes to only those relevant to that resource. This turns token issuance from a generic grant into a resource-specific authorization decision. In multi-resource environments, the practical effect is narrower blast radius and clearer trust boundaries between APIs.

Practical implication: configure token issuance around explicit resource URIs rather than relying on generic access tokens.

Audience validation on the resource server

Resource indicators are only effective when the receiving API validates that the token audience matches its own URI. If one billing API accepts a token issued for a profile API, the protocol boundary has failed even if the authorization server behaved correctly. This is why RFC 8707 and JWT validation are complementary controls, not alternatives. The authorization server constrains issuance, while the resource server enforces consumption. Without both, least privilege remains aspirational.

Practical implication: require every resource server to reject tokens whose aud value does not match its own identifier.

Why MCP authorization depends on RFC 8707

MCP introduces a class of OAuth client that may move across many resource servers in one session, which magnifies confused deputy risk. Resource-bound tokens make it harder for an AI-driven client to reuse one credential across unrelated endpoints. In practice, this shifts MCP auth design toward per-resource scoping, token cache partitioning, and tighter registration of what each audience is allowed to access. The protocol requirement is not decorative. It is the control that keeps agent-driven access from becoming ambient access.

Practical implication: design MCP auth so each resource URI has its own token boundary and cache key.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Audience-bound tokens are now a governance requirement, not a nice-to-have protocol detail. RFC 8707 addresses a structural weakness in OAuth deployments where one token can become valid for more than one resource server. That weakness is easy to overlook in traditional app-to-API patterns, but it becomes much more dangerous in multi-resource and MCP environments. The practitioner conclusion is straightforward: token audience is part of access governance, not just implementation plumbing.

Confused deputy risk is really an NHI boundary problem. When service-like clients, integrations, and agents can reuse tokens across resources, the identity model becomes too broad to govern cleanly. The issue is not simply that a token exists, but that its intended use is under-specified. That is why audience restriction belongs in the same control conversation as scope design, credential lifecycle, and API trust relationships.

Resource indicators sharpen the line between issuance and enforcement. The authorization server can issue a better-scoped token, but the resource server still has to reject misuse. This is the kind of split responsibility that identity programmes often underappreciate. If issuance and validation are not jointly owned, teams will misread protocol compliance as security control completion.

In MCP, token specificity becomes part of agent governance. Agents and other non-human clients tend to traverse more resources, faster, than human workflows do. That makes broad tokens especially hazardous because the access pattern is dynamic even when the identity is not autonomous. The implication is that IAM teams need to govern audience, scope, and cache behaviour together when they support MCP.

Resource URI stability is a hidden operational dependency. RFC 8707 relies on the resource identifier remaining consistent enough for both issuance and validation to agree. If teams treat URIs casually, they create avoidable breakage in authorization and logging correlation. The practitioner takeaway is that identity architecture must include naming discipline, not just token mechanics.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means many teams still lack the inventory needed to enforce token audience boundaries consistently.
• Audience-specific controls belong alongside the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 when teams design NHI and MCP governance.

What this signals

Audience-bound token design is becoming a baseline expectation for NHI and agentic access programmes. As agents and integrations fan out across more APIs, teams need controls that prevent token reuse from becoming silent privilege expansion. The governance question is no longer whether OAuth is supported, but whether the programme can prove that every token has a narrow, enforceable audience.

Resource URI discipline will matter more as MCP adoption grows. Teams that allow inconsistent naming, weak registration, or ad hoc token caching will find that authorization failures become operational failures. That is why identity governance now has to include the lifecycle of the resource identifier itself, not just the lifecycle of the credential.

With JetBrains GitHub plugin token exposure and OWASP Non-Human Identity Top 10 concerns around overbroad credentials, the practical direction is clear: scope is not a static policy field, it is a live trust boundary.

For practitioners

• Bind each token to a single resource URI Require authorization requests to include a resource parameter and verify that the resulting aud claim matches the intended API. Treat URI changes as controlled changes because they alter the trust boundary.
• Enforce audience validation at every API Configure each resource server to reject tokens whose aud value does not match its own URI, even when the token was issued by a trusted authorization server.
• Partition token caches by audience Key client-side token caches on both scopes and resource URI so a token issued for one API cannot be silently reused against another.
• Map MCP resources to explicit access rules Document which scopes belong to which MCP resource URIs and review those mappings alongside integration onboarding and offboarding.

Key takeaways

• RFC 8707 reduces OAuth token replay risk by binding access tokens to a declared resource server.
• Audience validation at the resource server is what turns token scoping into real enforcement.
• For MCP and other multi-resource integrations, token audience, cache partitioning, and URI discipline now belong in identity governance.

Key terms

• Resource Indicator: A resource indicator is a request-time signal in OAuth that tells the authorization server which resource server the token is meant for. In practice, it helps constrain the resulting token audience so access is tied to one API or logical service instead of being broadly reusable.
• Audience Claim: The audience claim is the value inside a token that identifies who or what should accept it. For non-human identity governance, it is the enforcement point that prevents a token issued for one resource from being accepted by another resource with a different trust boundary.
• Confused Deputy Problem: The confused deputy problem occurs when a trusted component uses its authority in a way that benefits the wrong requester or target. In OAuth and MCP environments, it appears when a token intended for one resource can be replayed against another, creating unintended access.
• Token Cache Partitioning: Token cache partitioning means storing and reusing access tokens only within the boundaries of their intended audience and scope. This prevents a client from treating a token issued for one resource as interchangeable with a token for another, which is especially important for multi-resource and agent-driven access.

Deepen your knowledge

Resource-bound OAuth and MCP authorization are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing token governance for multi-resource access, it is worth exploring.

This post draws on content published by WorkOS: Resource Indicators in OAuth 2.0, a guide to RFC 8707 and audience-bound tokens for secure MCP authorization. Read the original.