Some MCP servers don’t issue their own access tokens at all. They take the token your AI client already has — the one minted for a completely different audience — and forward it straight through to whatever backend API they wrap. MCP’s own authorization guidance calls this out by name as something servers should not do. Here is what token passthrough actually is, why it is tempting to build, and why it quietly breaks the safety guarantees the rest of the OAuth flow is supposed to provide.
What “passthrough” means here
In a correctly implemented MCP OAuth flow, the token your AI client presents to an MCP server is scoped to that server specifically — it names the server as its intended audience, per the resource-indicator mechanics OAuth 2.1 and RFC 8707 define for exactly this purpose. The server validates that the token was actually issued for it before honoring a request.
Token passthrough skips that step. The server accepts a token that was issued for some other resource — often the underlying API it’s wrapping, or an identity provider shared across several services — without checking that the token was ever meant for it, and then either uses that token directly against the backend or re-forwards it further downstream. It’s an easy shortcut to reach for: if the MCP server and the backend API already trust the same identity provider, forwarding the token “just works” in testing, and it saves the server from implementing its own token issuance and validation layer at all.
Why it’s tempting to build this way
A lot of MCP servers are thin wrappers over an existing API that already does its own auth — a SaaS product’s REST API, an internal service, a database. Standing up a proper OAuth authorization server in front of that wrapper is real work: token issuance, audience validation, refresh handling, revocation. Passing the caller’s token straight through looks like it gets you the same result — the backend still checks the token, still enforces its own permissions — for a fraction of the effort. That reasoning is the whole appeal, and it is also exactly where it goes wrong.
Why it breaks the model anyway
A few concrete failure modes follow directly from skipping audience validation:
- The token escapes its intended boundary. A token minted for “my identity provider” with no audience restriction can potentially be replayed against any service that trusts the same provider — not just the MCP server you meant to authorize. The server that accepts it without checking has no way to tell a legitimately scoped call from a token that was never meant to reach it.
- The server can’t enforce its own rules. Once a token is forwarded as-is, the MCP server has no independent record of what it actually approved — it’s relying entirely on whatever scope the token happened to carry for an unrelated purpose. There’s no place to apply MCP-specific policy — per-tool limits, session-level restrictions — because the server never issued the credential in the first place.
- It compounds with a confused deputy. We wrote about this pattern separately in the confused deputy problem in MCP: an agent using its own legitimate authority against you. A passthrough token raises the stakes on that same failure, because the credential doing the acting was never actually scoped to the tool that’s using it.
- Revocation gets murky. If three services all accept the same unscoped token, revoking access to one of them doesn’t necessarily revoke it everywhere else the token happens to work.
How to tell if a server does this
You can’t always tell from the client side alone — this is server implementation behavior, not something the OAuth consent screen surfaces. A few signals worth checking if you can see how a server is built, or ask the vendor directly:
- Does the server issue its own tokens, or does it accept whatever bearer token the client already holds?
- Does the server validate an
aud(audience) claim, or a resource indicator, before honoring a call? - If you revoke access at the identity provider, does the server actually stop working — or does a cached, unscoped token keep it going?
None of this is something a tool-description scan catches, because the problem isn’t in what a tool says it does — it’s in how the server validates who is allowed to call it. It sits at the same layer as the OAuth scope questions we covered in MCP OAuth scopes explained, one level below what the consent screen shows you.
What a well-built server does instead
The fix on the server side is straightforward to state, if not always trivial to build: issue tokens scoped to your own server as the audience, validate that audience on every request, and never forward a caller’s token to a downstream service as-is. If a server genuinely needs to call a backend API on the user’s behalf, it should exchange its own validated token for a separate, appropriately scoped backend credential — not hand the original token onward.
As a user, you mostly can’t fix a server’s token handling yourself. What you can do is treat it as one more reason to keep the blast radius small: connect servers through something that puts a policy layer between the client and the server rather than trusting the upstream OAuth grant alone, and revoke access at the gateway level when in doubt instead of assuming a single revocation reaches every place a token might have been forwarded. That’s part of what our MCP security page describes, and it’s the same reasoning behind vetting a server’s implementation, not just its tool list, before you connect it — see our checklist for vetting an MCP server.
The bottom line
Token passthrough is easy to build and easy to miss, because it often works fine right up until a token issued for one purpose gets used somewhere it was never meant to reach. If you’re building an MCP server, issue and validate your own audience-scoped tokens instead of forwarding whatever the client sends. If you’re connecting one, you likely can’t verify this yourself — treat it as another argument for a policy layer and a readable log in front of every server you connect, not just the ones that look risky on the surface.