MCP OAuth
The OAuth 2.1 authorization flow required by the Model Context Protocol spec for HTTP transports (March 2025 revision), tightened with mandatory Resource Indicators (RFC 8707) in the June 2025 revision. Resource Indicators bind an access token to a specific MCP server so a compromised or malicious server can't replay a user's token against a different downstream service — the fix for the *token passthrough* class of attack where early MCP servers forwarded a client's token unchanged to any downstream API. Correctly implemented MCP OAuth also uses PKCE, short-lived access tokens with automated refresh, and least-privilege scopes minted per-resource (per-repo GitHub PATs, per-channel Slack bot tokens) rather than broad user-wide scopes.
Written by Max Zeshut
Founder at Agentmelt · Last updated Sep 9, 2026
Frequently asked questions
- What is token passthrough and why is it dangerous?
- Early MCP servers accepted a user's OAuth token from the client and forwarded it unchanged to whatever downstream API they wrapped. Any compromised MCP server got the full scope of the token — often broad — and could replay it against unrelated services. Resource Indicators (RFC 8707) cryptographically bind each token to a specific audience, breaking the passthrough attack. As of mid-2026, roughly half the servers on public MCP registries still don't implement it — verify before you trust.