Answers · MCP security

What is a wrong-audience OAuth token in MCP, and how do I defend against it?

Short answer: A wrong-audience token is an access token that was issued for one resource (another API, another MCP server) but is presented to yours. If your MCP server accepts any token your authorization server signed, a token a user granted to some other server, or one a malicious server captured, can be replayed against you: the confused-deputy and token-passthrough problems. The MCP authorization specification closes this with audience binding: clients must send the RFC 8707 resource parameter naming your server's canonical URI when they request a token, and your server must validate that each token was issued specifically for it (its audience) and reject everything else. It must also never forward the token it received to an upstream API; get a separate token for that API.

Checklist

1. Publish OAuth Protected Resource Metadata (RFC 9728) at /.well-known/oauth-protected-resource naming your server's canonical URI and its authorization server(s).
2. Use one canonical resource URI for the server (scheme, host and path, such as https://mcp.your-domain.com/mcp) and make sure clients send exactly that as the RFC 8707 resource parameter in both the authorization and the token request.
3. On every request, validate the token fully: signature or introspection, issuer, expiry and not-before, and that the audience (aud, or the introspection response's audience) contains your canonical URI. Reject a token whose audience is missing or names something else, with HTTP 401.
4. Check scopes per tool call, not only at connect time, and answer 403 insufficient_scope when a token lacks the scope a tool needs.
5. Never pass the client's token through to an upstream API. Call upstream services with their own token, obtained for that audience (for instance by your own OAuth client or by token exchange, RFC 8693), and keep upstream tokens on the server.
6. If your server is a proxy to a third-party API, require per-client user consent before forwarding to the third-party authorization server, so a static client ID cannot be abused across users (the confused-deputy case in the MCP security best practices).
7. Keep access tokens short-lived, never log them, and log the token's issuer, audience and client ID on rejection so mis-issued tokens are easy to trace.

Why accepting "any valid token" is not enough

• A signature only proves who issued a token, not who it was for. Many authorization servers issue tokens for several resources with the same key, so a token for a calendar API and a token for your MCP server can both verify.
• Without an audience check, any server a user ever connected to can replay the tokens it received against every other server that trusts the same authorization server.
• Token passthrough makes it worse: the upstream API sees a token it trusts, but your server's own controls (rate limits, scope checks, audit logs) were skipped, and the upstream cannot tell which client really made the call.

What the specification requires

• The MCP authorization specification (2025-06-18 and later) requires MCP clients to implement RFC 8707 Resource Indicators and MCP servers to validate that tokens were issued specifically for them as the intended audience.
• It explicitly forbids MCP servers from accepting or transiting any other tokens.

Ask Rightshold (free, no key)

Add the MCP server https://www.rightshold.com/mcp to Claude, Cursor, ChatGPT, Grok or VS Code, then ask: “Before I connect this MCP server, is it a listed, vetted app and has its tool list changed recently?”

One-click setup

{
  "tool": "check_listing",
  "arguments": {
    "url": "<the server's URL or repository>"
  }
}

• Rightshold's own MCP endpoint needs no OAuth token for its free checks, so there is no token of yours for it to receive or pass on.
• registry_lookup and kya_lookup tell you who stands behind an agent before you grant it any token.

Rightshold does not test or certify another server's OAuth implementation. It reports what its store checks and listings actually found.

Sources

• MCP specification: Authorization
• MCP specification: Security Best Practices
• RFC 8707: Resource Indicators for OAuth 2.0
• RFC 9728: OAuth 2.0 Protected Resource Metadata
• RFC 9068: JWT Profile for OAuth 2.0 Access Tokens (audience validation)
• RFC 8693: OAuth 2.0 Token Exchange

Related

• How to vet an MCP server before installing it
• How to stop Log-To-Leak style prompt injection through MCP tools
• How do I verify an AI agent before doing business with it?

Not legal advice. Updated 2026-10-29. JSON · Markdown · All answers

curl -s -X POST https://www.rightshold.com/v1/accounts/signup -H "Content-Type: application/json" -d '{"accept_terms":true}'
export RIGHTSHOLD_API_KEY=rs_...   # the api_key from the reply (shown once)
curl -s https://www.rightshold.com/v1/licenses/check -H "Authorization: Bearer $RIGHTSHOLD_API_KEY" \
  -H "Content-Type: application/json" -d '{"license":"MIT","intended_use":{"commercial_use":true}}'