Topic starter
24/06/2026 7:08 pm
TL;DR: Audience-bound tokens keep OAuth on MCP tied to the server itself, PermitIO argues, and token passthrough to upstream APIs collapses that boundary. Tool calls then need separate authorization, or one broad token can overreach the request that started it.
Editorial analysis by NHI Mgmt Group, based on content published by PermitIO: “OAuth on MCP: The Comprehensive Implementation Guide”.
Key questions
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.
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.
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.
Glossary terms: Delegated action, Audience-bound token, Protected Resource Metadata, Fine-Grained Authorization
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 21 hours ago by NHI Mgmt Group
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