MCP OAuth: Why a Valid Token Can Still Be the Wrong Token

Do not fix an MCP audience error by turning off audience validation. A token can have a valid signature, a trusted issuer, and an unexpired lifetime while still being intended for a different application. First establish which resource the token was issued for; then treat permission to invoke a tool and credentials for its upstream API as separate decisions.

This guide is for operators of HTTP-based MCP integrations using OAuth. It uses the July 28, 2026 MCP specification, checked November 1, 2026. It is a documentation review, not a reproduced attack or a tested identity-provider configuration. Local stdio servers have a different starting point: see local MCP process permissions.

Why is this more than a connection problem?

AWS disclosed CVE-2026-115413 on October 27, 2026. Its AWS API MCP Server, package awslabs.aws-api-mcp-server, was affected in versions 1.3.0 through versions below 1.6.0, specifically with Streamable HTTP and OAuth authentication. The official advisory describes validation of signature, issuer, and expiry without validating the intended application. A local caller with another application’s token from the same configured identity-provider tenant could reach AWS API operations using host-configured credentials, bounded by those credentials’ permissions. Official advisory

AWS identifies 1.6.0 as the patched version and recommends upgrading to the latest release. OAuth operators must also configure the expected audience or client ID. The bulletin specifies AUTH_AUDIENCE, or AUTH_CLIENT_ID for providers whose access tokens lack an audience, such as Cognito. That is this product’s documented provider handling—not permission to substitute any client ID for audience validation in every OAuth deployment. AWS remediation guidance

The lesson is narrower than “all MCP is insecure”: a missing recipient check can expose an otherwise authenticated tool interface. The advisory does not establish that affected deployments forwarded the incoming bearer token to AWS.

Which resource should the client request?

Think of scope as the requested permission and resource as its destination, not interchangeable labels. RFC 8707 introduces the resource parameter so the authorization server can issue a token restricted to the intended protected resource. It does not make an arbitrary API token valid everywhere. RFC 8707, sections 1–2

For MCP, the client must include resource in both authorization and token requests. The value identifies the canonical MCP resource; the server must validate that incoming tokens were issued for it. MCP authorization security requirements

Before changing middleware, write down three separate identifiers from your approved configuration:

• The authorization server that issues the token.
• The canonical MCP resource the client intends to access.
• The upstream API the MCP tool may call afterward.

A login page completing successfully only settles one part of this chain. Do not infer the correct recipient from the fact that two services share an identity provider, organization, or hostname suffix.

Original conceptual diagram. A and B are labels, not credentials. Credential issuance and consent flows are omitted; the diagram does not prescribe a particular grant.

The token looks valid. What should the server check?

First identify the token format and the issuer’s supported validation profile. Decoding a JWT is not validation, and not every OAuth access token is a JWT. For the RFC 9068 JWT access-token profile, section 4 requires checks including token type, exact issuer match, expected audience, signature, and expiry. Successful cryptographic validation alone is insufficient. RFC 9068, section 4

For opaque tokens, the resource server may use the issuer’s supported introspection mechanism. RFC 7662 defines an active result and associated metadata; its meaning depends on authorization-server policy. Establish how that integration verifies the intended recipient and permissions rather than assuming an arbitrary active: true result authorizes every tool. Introspection caching also creates a freshness trade-off. RFC 7662, sections 2 and 4

Our operational recommendation is to record the failed check, not the bearer token: for example, “unexpected recipient” versus “expired” versus “tool permission denied.” Use access-controlled diagnostics with minimal metadata. Do not paste production tokens into public decoders, issue comments, screenshots, or support transcripts. If diagnostic sharing is necessary, use the HAR and log sharing checklist.

Can the tool reuse that token for another API?

Not as a shortcut. MCP’s authorization security requirements prohibit passing through the client’s token to an upstream API; upstream access must use separate credentials issued for that service. Passing validation at the MCP boundary is not a grant of every downstream permission. MCP token boundaries

Fictional example, not a captured exchange: an assistant accesses a reporting MCP service, which can read an accounting API.

• Token A is intended for the reporting MCP service. The MCP server validates A.
• The requested action is “read this month’s invoice summary.” The server separately checks whether this caller may perform that action for this tenant.
• The accounting request uses credential B, authorized for the accounting API and the necessary operation. It does not reuse A.
• If B is unavailable or lacks permission, the operation fails. Removing the API’s audience check is not a recovery strategy.

How B is obtained depends on the upstream service and your delegation model. This example does not claim every provider supports token exchange, nor that a server-wide service credential preserves user-level permissions. If your design uses shared service credentials, you must deliberately enforce which callers can invoke which operations and tenant data through them.

What should a safe acceptance checklist reject?

For your own implementation, define these expected outcomes before release. These are proposed acceptance criteria, not tests executed for this article:

• Reject a token for a different resource, even when issued by the same trusted issuer.
• Reject expired or otherwise invalid credentials under the applicable profile.
• Deny a valid caller an operation or tenant outside its authorization.
• Stop an upstream call when the separate upstream credential is missing or insufficient.
• Ensure diagnostics and error responses do not expose token values.

Use synthetic fixtures and a controlled environment; do not acquire another application’s credentials or probe third-party services. Passing this checklist would cover selected boundaries, not certify the whole system: consent handling, credential storage, revocation, network exposure, and tool behavior still need their own review.

Decision rule: repair the issuance and validation agreement, not the check that exposed the mismatch. Keep “who issued this?”, “is it for this resource?”, “may this caller invoke this tool?”, and “what authorizes the upstream request?” as separate questions.