OAuth Passthrough for MCP is a way for an AI agent or client to carry a user’s existing OAuth access context through an MCP connection without reauthenticating. In practice, the agent presents delegated OAuth tokens to tools so access decisions still follow the user’s identity, consent, scopes, and expiration.
How OAuth Passthrough for MCP Works
OAuth passthrough keeps the user’s existing delegated OAuth context intact across an MCP session instead of forcing a fresh login or substituting a separate machine credential. That makes the MCP client act as a carrier of user-approved access, not as a new decision-maker for the underlying scopes and token lifetime.
This pattern is most useful when the tool should act strictly on behalf of the user, with consent and authorization still anchored to the original OAuth grant. It is also where many implementations become fragile, because the architecture must preserve the right audience, issuer, and token handling rules across the client, the MCP server, and the downstream tool.
Why Passthrough Matters for Delegated Access
Passthrough preserves the security meaning of the original OAuth approval. The user’s identity, the consent granted, and the token’s expiry continue to govern what the tool may do, which is important when the action should remain attributable to the human user rather than to the agent or host application.
That distinction matters because delegated access is not the same as unconditional delegation. If a tool accepts an access token outside its intended audience, or if the MCP layer broadens what the token can reach, the result is no longer simple passthrough, it becomes a change in authority. For background on the underlying OAuth model, see RFC 6749: The OAuth 2.0 Authorization Framework.
Token Handling and Trust Boundaries
Passthrough creates a trust boundary problem: the client must transport sensitive bearer material without turning the MCP session into a token relay that can be replayed elsewhere. The most important design question is whether the server is acting as a true resource handler for the user or merely as a conduit that can unintentionally widen token exposure.
That is why MCP authorization guidance increasingly emphasises audience-bound tokens and explicit resource identification rather than loose forwarding. In practice, this means the MCP server and downstream tool must validate that the token was meant for them, and implementers should compare their design with the MCP authorization specification as the canonical reference.
Where an implementation also needs on-behalf-of delegation or token substitution, the safer pattern is controlled exchange, not casual reuse. The OAuth token exchange model is the relevant reference point for that distinction, as described in RFC 8693: OAuth 2.0 Token Exchange.
Common Failure Modes in MCP Passthrough Designs
Passthrough fails when developers treat the token as a generic session artifact instead of a narrowly scoped delegated credential. The biggest mistakes are forwarding a token to the wrong resource, extending its lifetime in transit, accepting tokens from an untrusted client context, or assuming that “user approved once” means “all downstream actions are acceptable.”
It also fails when the MCP layer becomes a confused deputy. If the server or agent can use the user’s OAuth context to reach more systems than the user intended, then consent is no longer controlling authority. For that reason, the surrounding control model should be read alongside RFC 8707: Resource Indicators for OAuth 2.0 and the current best practice guidance in RFC 9700: Best Current Practice for OAuth 2.0 Security.
Risk and Threat Considerations
OAuth passthrough can expose user tokens to theft, replay, overbroad delegation, and confused-deputy abuse if the MCP boundary is not tightly controlled. The risk rises when agents, gateways, and tools all touch the same bearer token without strong audience checks or sender-constrained protections.
Failure mechanism: A token that was valid for one delegated action is reused, forwarded, intercepted, or accepted by a different component, allowing an attacker or an overprivileged tool to act under the user’s authority.
Impact: Unauthorized tool actions, data exposure, and persistent access can result, especially where the token can be replayed before expiry or used across multiple downstream services.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth passthrough depends on secure token lifecycle handling and expiry. |
| AC-6 — Least Privilege | Passthrough should preserve only the user scopes needed for each MCP action. | |
| IA-2 — Identification and Authentication (Organizational Users) | The user identity remains the basis for delegated access decisions in passthrough flows. | |
| Recommendation — Manage delegated tokens as authenticators, including issuance, rotation, revocation, and replay resistance. Constrain each delegated token to the minimum permissions needed for the tool operation. Authenticate the user before issuing or forwarding any delegated OAuth context. | ||
| OWASP ASVS | V10 — OAuth and OpenID | OAuth passthrough is an OAuth delegation pattern and inherits OAuth protocol safety requirements. |
| Recommendation — Verify OAuth flows, token handling, and redirect and consent protections for delegated access. | ||
Practitioner Guidance
Why practitioners should care: OAuth passthrough is only safe when the delegation boundary is explicit. Treat the MCP client, server, and tool as separate trust domains and verify that each one preserves the user’s original consent rather than converting it into ambient access.
What to watch for: Review whether the token audience, expiry, and downstream resource mapping remain narrow at every hop, and whether the implementation can tolerate token leakage without broadening access. If the answer is no, the design needs tighter binding between the user grant and the exact tool action.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org