Because a bearer token without audience binding can be replayed against the wrong resource server. MCP servers should validate the aud claim and require clients to send a resource indicator so the authorization server can mint a token for the intended server. Without that boundary, a gateway becomes a confused deputy and forwards authority it was never meant to grant.
Why audience binding matters for MCP servers
MCP servers are resource servers, so they should accept only tokens minted for that specific server. Audience binding prevents a token that was valid somewhere else from being replayed at the wrong endpoint. It also keeps the authorization server, client, and resource server aligned on which resource is actually being protected.
That boundary matters because MCP often sits behind gateways, proxies, or aggregators. If the server accepts any bearer token that merely reaches the route, the route becomes a trust sink, and token presentation no longer proves the caller was authorized for that resource.
In practice, this is the difference between “the token is valid” and “the token is valid for this server.” The second statement is the security requirement. The first one alone leaves room for token forwarding, confused-deputy behaviour, and accidental authority transfer across tools or servers.
What the aud claim and resource indicator each do
The aud claim is the server-side check that binds a token to the intended audience. The resource indicator is the client-to-authorization-server signal that tells the issuer which protected resource the token should name. Used together, they make the token usable only at the target MCP server instead of being a generic access credential.
That design also reduces ambiguity in multi-resource deployments. A client may talk to several tools, each with different scopes or trust boundaries. Without resource indicators, the authorization server has less context about where the token should be valid, and the server has less evidence that the token was minted for it.
For MCP, this is especially important when a gateway is involved. The gateway may be a legitimate transport intermediary, but it should not become the place where broad bearer authority is accepted and then forwarded unchanged to downstream services.
Why accepting any bearer token creates a confused deputy
A bearer token proves possession, not intended use. If an MCP server accepts any bearer token that reaches it, an intermediary that legitimately holds one token can unintentionally carry authority into a different resource server. That is the confused deputy problem: a trusted component is tricked into spending authority outside its intended scope.
In MCP deployments, the deputy is often a gateway, relay, or client-side integration layer. The failure is not that the token is fake, it is that the token is valid somewhere else. Audience checks stop that replay path by forcing the token to match the actual server receiving the request.
This is why audience restriction is not just a nice-to-have control. It is what turns bearer possession into bounded authorization and keeps transport convenience from expanding into unintended access.
Risk and Threat Considerations
Without audience binding, a stolen or forwarded bearer token can be replayed against a different MCP server if the route accepts it. That increases blast radius, especially when a gateway, proxy, or shared client can reach multiple resources with different privileges.
Failure mechanism: The authorization server mints a token without a clear resource indicator, or the MCP server fails to validate aud, so a bearer credential usable in one context is accepted in another.
Impact: Attackers or misconfigured intermediaries can reuse tokens across servers, causing unauthorized tool access, privilege transfer through a gateway, and harder-to-detect cross-resource abuse.
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-5 — Authenticator Management | Audience-bound tokens rely on controlled token lifecycle and misuse resistance. |
| AC-3 — Access Enforcement | MCP servers must enforce access based on the token's intended audience. | |
| Recommendation — Treat access tokens as managed authenticators and rotate or revoke them when scope changes. Enforce server-side authorization checks that reject tokens minted for other resources. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Accepting any bearer token lets invalidly scoped tokens authenticate to the wrong server. |
| API5 — Broken Function Level Authorization | Wrong-audience tokens can expose functions the caller was never meant to reach. | |
| Recommendation — Require audience validation so bearer tokens cannot authenticate across unrelated MCP resources. Map each MCP function to the correct audience and reject tokens that do not match. | ||
Practitioner Guidance
What to verify: Confirm that the MCP server validates the token audience on every request path, including through gateways and reverse proxies, and that the client obtains a token for the intended resource rather than a generic one.
Decision rule: If the server cannot prove the token was minted for its own resource identifier, treat the request as unauthenticated for that server even if the token is otherwise valid.
What good looks like: Each MCP endpoint has a clear resource identity, the authorization server issues audience-specific tokens, and intermediary components forward requests without widening token scope.
Practitioner takeaway: The security boundary is the intended resource, not the transport hop, so MCP deployments should design for resource-specific tokens first and gateway convenience second.
