MCP authorization now depends on OAuth 2.1 and external auth

At a glance

What this is: This is a developer-focused analysis of the MCP authorization specification, with the key finding that secure remote MCP deployments depend on OAuth 2.1, PKCE, external authorization servers, and tighter metadata handling.

Why it matters: It matters because MCP is becoming a practical identity and access boundary for AI-connected tools, and IAM teams need to decide how to govern delegated access, token scope, and trust across machine and agent workflows.

👉 Read Descope's guide to MCP authorization with OAuth 2.1 and PKCE

Context

Model Context Protocol authorization is no longer a local developer convenience problem. As MCP moves into remote deployments, the core identity issue becomes delegated access for tools and agents that need to act across network boundaries without exposing passwords or reusable API keys.

The article focuses on the gap between specification and production reality. That gap sits squarely in NHI governance, because MCP clients, servers, and authorization servers must be separated cleanly if identity, token audience, and scope enforcement are going to survive enterprise deployment.

Key questions

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. Use OAuth 2.1 with mandatory PKCE, validate audience claims, and require external identity providers where possible. The main objective is to keep token issuance, token validation, and upstream access decisions distinct and auditable.

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. When the MCP server also issues tokens, it becomes harder to prove who authenticated, who authorized, and which resource the token was meant for. Separation keeps trust boundaries explicit and makes delegated access easier to govern.

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. That breaks authorization boundaries and can expose data or actions beyond the original MCP request. Each upstream dependency should receive its own token with its own audience and scope.

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.

Technical breakdown

OAuth 2.1 and PKCE in remote MCP deployments

MCP authorization uses OAuth 2.1 so clients can obtain delegated access without handling long-lived credentials directly. PKCE is mandatory for public clients because the code exchange can otherwise be intercepted during the authorization flow. In practice, this shifts MCP security from static credentials toward short-lived, standards-based token issuance. The important detail is that OAuth alone is not enough. The deployment pattern only works when clients, servers, and authorization servers each have a distinct role and the MCP server validates tokens against its own resource boundary.

Practical implication: treat MCP as a delegated access path and require PKCE for every public-client flow.

Dynamic client registration and authorization server metadata

Dynamic Client Registration lets an MCP client register programmatically instead of being manually pre-approved, while Authorization Server Metadata lets the client discover the right authorization endpoints. Together, they reduce integration friction, but they also introduce trust questions. If registration is anonymous or poorly verified, the authorization server may issue credentials to clients it cannot reliably identify. Metadata discovery solves endpoint confusion, not client trust. That distinction matters because remote MCP deployments need both interoperability and a defensible registration posture.

Practical implication: pair discovery with client verification, and do not rely on registration convenience as a trust control.

Resource indicators, token passthrough, and confused deputy risk

The specification now pushes MCP servers to act as resource servers only, not as combined resource and authorization servers. That separation matters because a server that reuses an incoming token for upstream calls can create confused deputy failures, where downstream APIs trust a token that was never intended for them. Resource indicators and protected resource metadata help bind tokens to the correct audience, but only if the server validates them consistently. The operational lesson is that token routing is part of identity design, not just application plumbing.

Practical implication: block token passthrough, validate audience claims, and issue separate tokens for upstream APIs.

NHI Mgmt Group analysis

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.

Dynamic registration improves onboarding, but it does not prove trust. DCR can make MCP client setup faster, yet anonymous registration still leaves open the question of whether the client is legitimate. That is why verification becomes part of identity governance, not a post-authentication afterthought. The practitioner conclusion is that registration workflow design must be reviewed as a control surface, not a convenience feature.

Token passthrough is a governance failure mode, not an implementation shortcut. When an MCP server forwards a client token to another API, it collapses the separation between intended audience and actual use. That breaks the assumption that delegated access remains bounded to one resource server and one decision point. The practitioner conclusion is that downstream authorization must be explicit, separate, and auditable.

Function-level scope design is where agent experience and control discipline meet. MCP tool calls do not always map cleanly to API endpoints, so scope decisions must happen at the function or tool level rather than through broad catch-all access. That creates a practical governance test for IAM and platform teams: can they authorise narrowly enough without forcing unusable prompts or over-broad scopes? The practitioner conclusion is that scope design needs to be reviewed alongside workflow design, not after deployment.

Remote MCP makes identity metadata a production dependency. As organizations shift from local to remote MCP, the authorization server metadata, protected resource metadata, and audience validation chain become part of runtime resilience. That aligns directly with OWASP NHI concerns around credential scope, service trust, and token misuse. The practitioner conclusion is that MCP should be evaluated as an identity control plane, not only as a protocol feature set.

From our research:

• 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.
• For teams extending MCP into agentic workflows, that blind spot makes scope design and token governance inseparable from control design, as discussed in OWASP NHI Top 10.

What this signals

Function-level scopeing is becoming the practical control boundary for remote MCP. As tool calls move beyond local execution, teams need a permission model that reflects actual functions rather than broad API access. That is why the governance conversation should shift from endpoint protection to identity-aware task authorization, with protected resource metadata and audience validation supporting the control plane.

With 98% of companies planning to deploy even more AI agents within the next 12 months, the MCP authorization model is not a niche protocol issue. It is part of a wider shift in which machine access patterns are becoming more dynamic, more distributed, and harder to certify after the fact, which is why the OWASP Agentic AI Top 10 is increasingly relevant to identity teams.

Identity metadata is now operational infrastructure. Remote MCP deployments depend on discovery documents, registration decisions, and token audience rules to keep authorization trustworthy. Teams that still treat these as integration details will struggle to prove who the client was, what it could do, and which service actually received the token.

For practitioners

• Separate resource-server and authorization-server roles Configure MCP servers to validate externally issued tokens instead of issuing or brokering credentials themselves. This keeps identity ownership centralized and makes the enforcement boundary easier to audit.
• 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. That prevents confused deputy failures and keeps audience claims aligned with each API.
• Harden dynamic client registration Use verification flows, IP reputation checks, and risk-based controls before allowing runtime registration. Treat DCR as a trust workflow, not just an onboarding shortcut.
• Validate scopes at the function level Map permissions to specific tools or functions instead of using broad access scopes that do not reflect actual agent actions. This reduces over-authorization while preserving usable Agent Experience.
• Enforce metadata-driven discovery Publish and consume protected resource metadata and authorization server metadata so clients do not rely on hardcoded endpoints. That improves interoperability and reduces misconfiguration risk across remote deployments.

Key takeaways

• MCP remote authorization depends on explicit delegation boundaries, not just OAuth branding.
• DCR and metadata discovery simplify onboarding, but they do not establish trust on their own.
• Teams must stop treating token passthrough and scope mapping as implementation details, because both determine whether MCP access remains governable.

Key terms

• Model Context Protocol Authorization: The identity and access layer that lets an MCP client obtain permission to use a remote MCP server. It combines delegated authorization, token validation, and resource discovery so tools can access data without shared passwords or ad hoc credentials.
• Dynamic Client Registration: A mechanism that allows a client to register with an authorization server at runtime instead of being manually pre-registered. In MCP deployments, it reduces onboarding friction, but it also increases the importance of client verification and trust controls.
• Protected Resource Metadata: A discovery document that tells a client how to find the correct authorization details for a protected resource. In remote MCP, it helps bind token requests to the right server, but it does not replace validation of client trust or token audience.
• Confused Deputy Risk: A failure mode where a trusted service uses a token or request on behalf of the wrong party. In MCP, this often appears when a server passes a client token downstream instead of obtaining its own token for the next API call.

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.

👉 Descope's full post covers the MCP authorization flow, deployment trade-offs, and open implementation questions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.