OAuth and Token Passing in MCP: Should Servers Forward Access Tokens? (Security 2)

When an agent calls an MCP tool on behalf of a signed-in user, something has to authorize the downstream API. The tempting shortcut is to hand the user's access token to the MCP server and let it forward that Bearer token unchanged. That pattern is easy to build and easy to get wrong.

This article explains the risks of pass-through tokens, when (if ever) forwarding is acceptable, and the safer alternatives: on-behalf-of exchange, short-lived scoped tokens, and keeping secrets out of tool results.

The pass-through temptation

A typical flow looks like this:

1. The user signs in to your app (Entra ID, Auth0, Cognito, …).
2. The agent or host attaches Authorization: Bearer <user_access_token> to the MCP session or to each tool call.
3. The MCP server copies that header to Salesforce, GitHub, your internal REST API, or a database gateway.

It feels correct because the downstream call is still "as the user." The problems show up in the details.

What goes wrong

Over-broad tokens. User access tokens often carry many scopes. Your MCP tool only needed orders.read, but the token also allows users.admin. Anyone who steals that token from the MCP process gets the full set.

Wrong audience. Access tokens are minted for a specific audience (your API). Forwarding them to another API either fails validation or, worse, some stacks accept them loosely. Tokens meant for the MCP host should not be accepted by every backend.

Leakage into logs and model context. Frameworks log headers. Agents dump tool arguments and errors into prompts. A stack trace or verbose isError payload can print a Bearer token into a transcript that operators, other tools, or the model can see.

Replay. Long-lived tokens stolen from memory, disk caches, or CI logs can be replayed until expiry. MCP servers that persist "session" state make this worse.

Confused deputy. The MCP server becomes a deputy that can be tricked into using the user's token for an action the user did not intend—especially if tool arguments come from untrusted content (see the prompt-injection article in this series).

Prefer: never forward the raw user token

The default design should be:

1. The host authenticates the user and establishes an MCP session with a server-side session id, not a raw access token in every tool payload.
2. When a tool needs a downstream API, the MCP server (or a sidecar) performs token exchange / On-Behalf-Of (OBO) to mint a new, short-lived, audience-bound token with minimal scopes for that API only.
3. Tool results return data, never credentials. Strip Authorization values from any error text before it reaches the model.

On Microsoft Entra ID this is the OBO flow. On other IdPs look for token exchange (RFC 8693) or a backend-for-frontend that holds refresh tokens and issues API-specific credentials.

Decision guide

If you must pass a token for a prototype:

• Scope it to one audience and one short lifetime (minutes).
• Send it only over TLS, never as a tool argument the model generated.
• Store it in memory only; do not write it to MCP resource bodies or logs.
• Rotate and revoke aggressively; disable the pattern before production.

Implementation checklist

• Downstream tokens are minted for the API audience, not reused from the chat app's audience.
• Scopes are the minimum the tool needs; separate read and write tools.
• MCP tool schemas never include a access_token argument for the model to fill in.
• Logs and traces redact Authorization and known token patterns.
• Replay defenses: short expiry, sender-constrained tokens (DPoP / mTLS) where available.
• Human approval for high-impact tools even when the token is scoped.

An MCP server should prove who the user is without becoming a free-floating holder of their master key. Exchange for the narrowest token you need, bind it to the right audience, and keep Bearer strings out of prompts and logs.

Related reading

• Securing MCP Server Database Connections: Direct, API, and Beyond: keep credentials off the model and behind least-privilege paths—the same separation applies when the "credential" is an OAuth access token.

About the author

I write about Applied AI, MCP, Azure AI Search, and RAG. Follow me on Dev.to and Hashnode for more.