Topic starter
24/06/2026 7:08 pm
TL;DR: OAuth on MCP separates client authentication from tool-level authority, but the 2025-06-18 spec still requires tokens to be issued for the MCP server itself and not passed through to upstream APIs, according to PermitIO. The real governance failure is assuming bearer tokens alone can safely authorize agentic tool calls; they cannot.
Editorial analysis by NHI Mgmt Group, based on content published by PermitIO: “OAuth on MCP: The Comprehensive Implementation Guide”.
Key questions
Q: What breaks when an MCP server passes client tokens to upstream APIs?
A: Token passthrough creates confused deputy risk because downstream services may accept a token that was issued for a different audience.
Q: Why do OAuth scopes not work well for MCP tool authorization?
A: OAuth scopes are coarse and fixed at token issuance, while MCP decisions are often per call and depend on the user, the tool arguments, and the specific record involved.
Q: How should security teams govern MCP servers that wrap REST APIs?
A: Security teams should govern MCP servers as agent-facing identity surfaces, not as simple API adapters.
Practitioner guidance
- Separate MCP and upstream tokens Issue an access token for the MCP server audience and keep any GitHub or other upstream credential inside the server's trusted boundary.
- Enforce policy at each tool call Evaluate subject, tool name, arguments, tenant, session, and environment before allowing tools/call execution.
- Require resource metadata discovery Make the MCP server publish protected resource metadata and require clients to discover the authorization server from that metadata before any token exchange.
Bottom line: OAuth on MCP only works when the server is treated as a protected resource with its own audience-bound token boundary.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 4:17 am
Audience binding is the real control plane on MCP: OAuth on MCP only works when the token is issued for the MCP server itself, not for a downstream API that the server happens to call. That breaks the old assumption that a bearer token can be treated as generic proof of delegated intent. In identity terms, the protected resource boundary now matters as much as the login event, and practitioners should model that boundary explicitly.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What is the difference between coarse OAuth scopes and fine-grained authorisation in MCP?
A: Coarse scopes describe broad capability classes such as read, write, or admin, while fine-grained authorisation decides whether this specific call is safe in this specific tenant, session, and context. Scopes label the door; policy decides whether the room should open.
👉 Read our full editorial: OAuth on MCP exposes the boundary between login and delegated action