Validate MCP Token Audience
Reject an MCP access token issued for another resource, even when its issuer and lifetime are valid.
An access token can be active and still be wrong for an MCP server. MCP does not require a JWT format; the issuer may use a signed JWT or an opaque token. The audience identifies the resource the token was meant to reach. If the server accepts a token minted for another API, a client may cross a boundary that the authorization server intended to keep separate. The MCP authorization specification treats protected resource metadata and token validation as part of HTTP-based authorization.
Start with the resource identifier your MCP server publishes. Record the trusted issuer, the accepted audience value, the scope mapping, and the issuer's token-validation contract. Do not infer the audience from an arbitrary request header or from the model's tool arguments. A local stdio server has different credential handling; this article concerns HTTP transport.
Validation matrix
| Token case | Expected server result |
|---|---|
| Correct issuer, audience, scope, and active lifetime | Permit only the mapped tool |
| Verified token, wrong audience | Deny before tool execution |
| Correct audience, missing required scope | Deny the protected tool |
| Unknown issuer, invalid JWT signature, or inactive opaque token | Deny and record a safe reason |
| Expired or not-yet-valid token | Deny without retrying upstream |
| No token on a protected route | Challenge or deny as configured |
Implement checks in the server's authentication boundary before tool dispatch. Confirm the audience comparison uses the complete resource identifier, not a substring or a permissive suffix. For a JWT, verify its signature with keys from the configured issuer and reject algorithms chosen only by untrusted token metadata. For an opaque token, use the issuer's authenticated introspection contract to check active state, audience, scope, and lifetime; never parse the opaque value as though it contained claims.
Evidence to keep
Use synthetic JWT and opaque tokens from an owned authorization test fixture. Run one permitted call and each denial case against a harmless tool. Capture the HTTP status, tool invocation count, and a redacted correlation ID. A denial is incomplete if the handler ran and only the final response was blocked. Also test a token for a related service issued by the same authority; this is the case an issuer-only check misses.
If the authorization server cannot issue a resource-bound token, do not treat a broad token as equivalent. Document the limitation and keep the protected tool unavailable until the trust contract is explicit. Recheck the matrix after changing issuer configuration, proxy routing, or tool scopes. Token validation is not a substitute for object-level authorization: a correctly addressed token can still ask for another tenant's record.
Know what your agents can reach
Map data access, tool actions and approval boundaries before testing. Use the scope guide, or discuss a review of your AI application.
Sources
- MCP Authorization SpecificationAccessed
- MCP Security Best PracticesAccessed
- RFC 7662: OAuth 2.0 Token IntrospectionAccessed