Notifications
Clear all
Topic starter
06/07/2026 9:38 am
TL;DR: MCP authorization now rests on OAuth 2.1, mandatory PKCE, external authorization servers, and tighter resource metadata handling as remote deployments replace local-only assumptions, according to Descope. The governance question is no longer whether MCP can authenticate, but whether teams can keep tool access, token audience, and delegation boundaries clean enough to trust.
NHIMG editorial — based on content published by Descope: Diving Into the MCP Authorization Specification
Questions worth separating out
Q: How should security teams govern MCP authorization in remote deployments?
A: Security teams should treat MCP as a delegated access boundary and separate the resource server from the authorization server.
Q: Why do MCP servers need external authorization servers instead of managing auth themselves?
A: External authorization servers reduce role confusion and align MCP with established enterprise identity patterns.
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 resource-server and authorization-server roles Configure MCP servers to validate externally issued tokens instead of issuing or brokering credentials themselves.
- Disable token passthrough to upstream APIs Require the MCP server to obtain its own token when it calls another service, rather than forwarding the client token.
- Harden dynamic client registration Use verification flows, IP reputation checks, and risk-based controls before allowing runtime registration.
What's in the full article
Descope's full developer guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of the OAuth 2.1 flow used by MCP clients and servers.
- Detailed treatment of Dynamic Client Registration, including how registration and verification differ in practice.
- Examples of Protected Resource Metadata and Authorization Server Metadata handling for remote deployments.
- Discussion of SSE error handling and token lifecycle edge cases that implementation teams need to resolve.
👉 Read Descope's guide to MCP authorization with OAuth 2.1 and PKCE →
MCP authorization and OAuth 2.1: what changes for security teams?
Explore further
06/07/2026 9:53 am
Access design for MCP only works when token boundaries stay explicit. The article shows that MCP remote authorization becomes viable when the server behaves as a resource server and external identity systems own token issuance. That is an NHI governance pattern, not just an API pattern, because the control point is the identity boundary around machine access. The practitioner conclusion is that any MCP deployment that blurs issuer, audience, and enforcement roles is already weakening its own trust model.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
A question worth separating out:
Q: Who is accountable for MCP scope design when tool calls do not map cleanly to APIs?
A: The platform and IAM teams are accountable for defining scope granularity that matches real tool behavior. Broad scopes increase privilege, while overly fine scopes can create unusable workflows. The practical answer is to map scopes to functions, enforce them consistently, and review them whenever the tool set changes.
👉 Read our full editorial: MCP authorization now depends on OAuth 2.1 and external auth
