Cybersecurity · MCP security · 8 min
Tokens, OAuth and the “confused deputy”: preventing unauthorized access
When a server acts on behalf of a person toward another service, it must preserve the identity, consent and scope of each authorization.
Introduction
A token is not just a string that lets you “connect” a service: it represents a bounded authority. In systems with proxies or chained integrations, confusion about whom that authority represents can turn the server into a confused deputy.
What MCP specifies and what it does not
MCP authorization is optional. For implementations that offer it over HTTP, the 2025-11-25 specification defines an OAuth-based flow and requires, among other points, that the server implement Protected Resource Metadata (RFC 9728) and that the client use it to discover authorization servers. The server acts as a resource server and the client as an OAuth client. That flow should not be automatically extrapolated to stdio: the specification recommends not using it there and retrieving credentials from the environment instead.
Those obligations are specific to the authorization mechanism described by MCP. They do not replace the analysis of authorization between the MCP server and a third-party API.
Avoiding the “confused deputy”
The risk appears, for example, when a proxy uses its own credentials for an external API but does not properly check which MCP client it is serving, nor keep an individual approval. MCP’s best practices describe a particular scenario that combines a static OAuth identifier, dynamic client registration, a third-party consent cookie and the absence of per-client consent. This does not imply that every MCP OAuth flow is vulnerable.
Bind each flow to its client and user; validate redirect_uri, state and destination; do not reuse tokens across users or clients; ask for clear consent before delegating; restrict scopes and audience; protect tokens in storage and logs. Also apply RFC 9700, the OAuth 2.0 Best Current Practice, as OAuth security guidance, without confusing it with an MCP specification.
Conclusion
The key question is not just “is there a token?” but “who obtained it, for which resource, on whose behalf and under what consent?”. Preserve those relationships across every hop.
Sources and rigor
References
References verified on September 25, 2026. The specification may change; check the current versions before making implementation decisions.
Conclusion
The key question is not just “is there a token?” but “who obtained it, for which resource, on whose behalf and under what consent?”. Preserve those relationships across every hop.
Keep exploring