OAuth resource indicators harden MCP server token audience binding

At a glance

What this is: This article explains how OAuth resource indicators bind MCP access tokens to a specific server audience and prevent token reuse across servers.

Why it matters: It matters because IAM teams building MCP and AI-connected services need token boundaries that match the actual trust boundary, not a generic auth server default.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read WorkOS's guide to securing MCP servers with OAuth resource indicators

Context

MCP server security depends on whether the token presented to a server was actually minted for that server. In multi-server agent workflows, a generic bearer token can become a reusable credential if audience binding is missing, which turns a local authorization decision into a cross-server exposure problem.

For identity teams, the issue is not just OAuth correctness. It is whether the MCP trust boundary is enforced at token issuance, token validation, and client handling in a way that prevents one server, tool, or intermediary from accepting credentials meant for another.

That is why resource indicators matter in practice: they align the token audience with the protected resource, which is the minimum condition for predictable authorization in MCP deployments.

Key questions

Q: How should security teams implement audience-bound tokens for MCP servers?

A: Security teams should bind each token to a single MCP server, validate the aud claim at the resource server, and make clients request the same resource URI during authorization and token exchange. The goal is to prevent a token issued for one server from being accepted by another, even if the issuer is shared.

Q: Why do MCP environments need resource indicators if OAuth scopes already exist?

A: Scopes limit what a token can do, but they do not say where that token may be used. Resource indicators add the destination boundary, which stops a narrow token from being replayed against the wrong MCP server. In multi-server agent workflows, that separation is essential for least privilege.

Q: What breaks when MCP tokens are accepted without audience checks?

A: Without audience checks, a token can become a reusable credential across multiple servers that trust the same authorization authority. That creates token reuse risk, confused deputy conditions, and a larger blast radius if the token is stolen or forwarded by a client or intermediary.

Q: Who is accountable if an MCP server accepts the wrong audience token?

A: Accountability sits with both the authorization server operator and the MCP server operator. The issuer must bind tokens to the correct resource URI, and the resource server must reject mismatched tokens. If either side skips that control, the boundary fails and the resulting access is not defensible.

Technical breakdown

OAuth resource indicators and the aud claim

Resource indicators extend OAuth 2.0 by letting the client specify which resource server the token is for at request time. The authorization server then stamps the token with an audience claim, usually aud, that the resource server can validate before honoring the request. Without that binding, a token can become broadly acceptable anywhere the issuer is trusted. In MCP, this matters because clients often touch multiple servers in one session, and each server must be treated as a separate trust boundary, not a shared backend.

Practical implication: require audience validation on every MCP server that accepts OAuth tokens.

Confused deputy risk in multi-server MCP sessions

A confused deputy problem appears when a component that has authority on its own becomes a conduit for authority intended for somewhere else. In MCP, a server or client may receive a token for one resource and then forward or reuse it against another if audience checks are weak. That is especially risky in agentic workflows where tools, servers, and upstream services can all sit inside one execution chain. Resource indicators reduce that replay path by making destination-specific tokens explicit.

Practical implication: do not allow token forwarding across MCP servers unless the audience is preserved and revalidated.

Token scope is not the same as token audience

Scopes tell a token what actions it may perform. Audience tells it where those actions are allowed. Those two controls solve different problems and both are needed in MCP because narrow scopes do not stop a credential from being presented to the wrong server. Implementation breaks most often when teams validate signature and expiry but skip audience, or when client code requests the right scope but omits the resource parameter during token exchange.

Practical implication: treat scope review and audience review as separate implementation checks in MCP auth testing.

NHI Mgmt Group analysis

Audience-bound tokens are now a baseline control for MCP, not an advanced option. MCP environments are inherently multi-server, so a bearer token without resource binding is structurally too broad for the trust model the protocol creates. The governance question is no longer whether OAuth works, but whether the token lifecycle preserves a server-specific boundary from issuance to acceptance. Practitioners should treat audience validation as the minimum viable control for MCP deployments.

Token reuse across MCP servers is an identity boundary failure, not just an auth bug. When one credential can be replayed against multiple servers, the access model has already lost its containment property. That weakens least privilege at the protocol layer because the token is no longer tied to a single protected resource. The practical conclusion is that multi-server MCP architectures must be designed around per-server credential scoping, not shared credential assumptions.

Resource indicators expose a wider secret-governance lesson for machine identity: a token is only safe when its intended recipient is unambiguous. The same discipline applies to service accounts, API keys, and agent-facing credentials, where audience, scope, and revocation must line up. In MCP, the named concept is audience-bound token discipline: a token that cannot be interpreted outside its intended server boundary. Identity teams should use that concept to re-evaluate how they issue and validate every non-human credential.

Lifecycle controls matter here because MCP clients may hold multiple server-specific tokens at once. If issuance, refresh, expiry, and revocation are handled inconsistently, the client becomes a de facto credential broker with its own blast radius. That is why machine identity governance has to include token inventory and audience-aware rotation, not just login plumbing. Practitioners should manage MCP credentials as bounded identities with explicit server ownership.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• The secret sprawl challenge shows why audience binding must sit alongside revocation and inventory controls in machine identity programmes.

What this signals

Audience-bound token design will matter more as MCP adoption expands, because multi-server agent workflows create credential paths that traditional app-centric IAM models were never built to separate. Teams should expect auth servers, resource servers, and client libraries to be evaluated together rather than as independent components.

Audience-bound token discipline: the practical standard is that every non-human credential must have one clearly intended recipient and one enforcement point. That principle applies to MCP tokens, service account secrets, and workload identities alike, and it is where governance failures become visible first.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, credential governance is already a scale problem, not a theoretical one, and the safest MCP architectures will be the ones that can prove token containment, not merely token issuance.

For practitioners

• Enforce audience validation on every MCP server Configure resource servers to reject tokens whose aud claim does not exactly match the server's canonical resource URI, and test both valid and invalid audience cases before production.
• Require the resource parameter in both auth steps Make clients send the resource parameter during authorization and token exchange so the authorization server issues a token that is explicitly bound to the intended MCP server.
• Standardise canonical resource URIs Publish one exact URI format for each MCP server and use it consistently in metadata, client configuration, token issuance, and validation to avoid mismatches caused by trailing slashes or scheme drift.
• Test token rejection paths, not just happy paths Verify that wrong-audience tokens fail closed with a clear invalid_token response, because permissive fallbacks erase the security value of resource indicators.

Key takeaways

• MCP token security depends on proving the intended audience, not just verifying that a token is valid.
• Multi-server agent workflows create replay and confused deputy risks unless each server enforces its own audience boundary.
• Identity teams should treat audience validation, URI consistency, and rejection testing as mandatory controls for MCP deployments.

Key terms

• Resource Indicator: An OAuth parameter that tells the authorization server which protected resource the token is meant for. In MCP, it turns a generic bearer token into a server-specific credential, which reduces replay risk and makes the intended access boundary explicit.
• Audience Claim: A token claim, usually aud, that identifies the resource server allowed to accept the token. For MCP deployments, audience validation is the practical enforcement point that prevents a valid token from being reused across a different server.
• Confused Deputy: A failure mode where a trusted component is tricked into using its authority on behalf of the wrong party. In MCP, this happens when a server or client forwards a token outside its intended audience, turning a local authorization decision into a broader access problem.
• Machine Identity: A non-human identity used by software, workloads, APIs, or agents to authenticate and access services. In this context, machine identity governance depends on scoping, audience binding, and revocation so credentials cannot be reused outside their intended boundary.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by WorkOS: How to secure your MCP server with OAuth resource indicators. Read the original.