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.
At a glance
What this is: This is a Descope analysis of the MCP authorization specification, with the key finding that remote MCP deployments now require OAuth 2.1 patterns such as mandatory PKCE, external authorization servers, and tighter resource metadata handling.
Why it matters: It matters because IAM, PAM, and NHI teams need to decide how MCP tools obtain, validate, and scope delegated access before remote deployments turn protocol ambiguity into governance debt.
Context
MCP authorization is moving from an assumed local trust model to a delegated remote access model. That changes the identity problem from simple connectivity to controlled authorization, because an MCP client may now act on behalf of a user across network boundaries.
The article focuses on how OAuth 2.1, PKCE, dynamic client registration, and resource metadata fit together when MCP servers are deployed remotely. For identity teams, the important question is whether the server remains a resource server with externally governed authorization, or drifts into acting as its own trust authority.
Key questions
Q: What breaks when an MCP server has no clear authorization boundary?
A: Without a clear authorization boundary, teams are forced to improvise trust decisions inside the server logic itself. That creates ambiguity around who issued the token, what claims are trusted, and how consent is enforced. In practice, the result is fragile integrations, inconsistent scope handling, and a much higher chance that agent requests exceed intended permissions.
Q: Why does token audience validation matter for remote MCP deployments?
A: Audience validation ensures a token was issued for the specific MCP resource that is consuming it, not for some other service in the chain. Without that check, reused tokens can create confused deputy failures, especially when MCP servers call upstream APIs or support multiple authorization contexts.
Q: How should security teams handle Dynamic Client Registration in remote MCP deployments?
A: Security teams should treat Dynamic Client Registration as a high-risk identity workflow, not a convenience feature. Require layered verification, limit where registration can originate, bind permissions to specific tool functions, and make revocation immediate. The goal is to preserve scale without letting unknown clients inherit trust before they have earned it.
A: Protected resource metadata describes the MCP server, including which authorization servers it trusts, what token formats it accepts, and how a client can verify tokens. Authorization server metadata describes the issuer, login endpoint, token endpoint, registration endpoint, supported grant types, and client authentication methods. Together, they let clients discover both sides of the flow without hardcoded integrations.
Technical breakdown
Why OAuth 2.1 and PKCE are now the MCP baseline
MCP uses OAuth 2.1 to delegate access without sharing passwords or static API keys, and PKCE is mandatory for public clients because authorization code interception is a realistic risk in browserless and CLI-style flows. The key design shift is that remote MCP access is no longer a local trust shortcut. Instead, the protocol depends on standard OAuth protections that were built for untrusted network paths and third-party clients.
Practical implication: Treat every remote MCP client as a public OAuth client unless you have a specific, defensible reason not to.
Why MCP servers should act as resource servers only
The specification's newer model separates the MCP server from the authorization server, which matters because it removes login, issuance, and token lifecycle duties from the tool host itself. That separation reduces trust concentration and fits enterprise identity architecture, where the IdP remains the authority and the MCP server only validates tokens and enforces local authorization. The practical gain is clearer delegation boundaries and less protocol ambiguity.
Practical implication: Keep MCP servers out of the authorization-server role unless you have a strong reason to accept the added governance burden.
How resource metadata and token audience prevent confused deputy failures
Protected Resource Metadata and resource indicators make the client discover the correct authorization server and make the server validate that a token was issued for that specific resource. Without those checks, a token can be accepted in the wrong place, which is the classic confused deputy problem in delegated systems. In MCP, that risk grows when the server also calls upstream APIs and reuses the wrong token downstream.
Practical implication: Validate audience, issuer, and resource metadata for every MCP token before allowing tool execution or upstream API calls.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Delegated MCP access is now an identity governance problem, not just a protocol choice. Once MCP moves off localhost, the real issue is who is allowed to obtain tool access, under what issuer, and with what audience constraints. OAuth 2.1 is the mechanism, but governance still has to define the trust boundary. Practitioners should treat remote MCP as a delegated access programme with explicit control ownership.
Tool hosts should not become auth authorities by accident. The June 2025 separation between MCP servers and authorization servers is not just cleaner architecture, it prevents identity sprawl inside the tool plane. When the server issues tokens, stores OAuth state, or brokers trust for itself, accountability becomes harder to audit and offboarding becomes less deterministic. The practical implication is to keep issuance and enforcement in different control domains.
Resource metadata is the control that keeps delegation from becoming ambient trust. Resource indicators, protected resource metadata, and token audience checks are the difference between intended access and reusable access. That matters because MCP tool calls can be proxied, chained, or forwarded, and each hop expands the chance of confused-deputy behavior. Practitioners should treat audience binding as a core governance control, not a technical nicety.
Dynamic client registration creates an onboarding trust problem, not just an automation benefit. DCR makes MCP integration easier, but anonymous registration without verification produces a new identity admission surface. That is why the open questions around client metadata, IP reputation, and risk-based controls matter: the protocol is asking organisations to prove who is asking for trust before trust is issued. The implication is that registration policy becomes part of identity governance.
Remote-first MCP exposes an identity blast radius problem: scope discovery, delegation, and upstream token handling now share one failure domain. If teams allow tool scopes, audience checks, and downstream token reuse to drift apart, they create trust leakage across the whole agent-to-tool path. Practitioners should govern MCP as a bounded delegation chain, not as a set of isolated implementation choices.
From our research library:
- 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.
- Read next: AI Agent Authorisation Guide
What this signals
Remote MCP shifts access control from a local implementation concern to a delegated identity boundary. Teams that already govern OAuth clients, scopes, and issuers will be better placed to absorb MCP than teams treating it as a simple developer integration. The practical test is whether the MCP program can prove who registered a client, who issued the token, and which resource the token was meant for.
Resource-bound delegation will become the main control question for MCP programs. As soon as the same client can discover, request, and forward tokens across multiple services, the blast radius of weak audience binding grows quickly. That makes resource metadata, registration policy, and downstream token handling part of the same governance conversation.
For practitioners
- Separate authorization from resource hosting Keep MCP servers in the resource-server role and use an external authorization server for token issuance, discovery, and policy ownership.
- Enforce mandatory PKCE for public clients Require PKCE on all authorization code flows used by CLI tools, desktop clients, and other public MCP clients that cannot safely hold secrets.
- Bind every token to the intended MCP resource Validate resource indicators, issuer, and audience before accepting any MCP token, including tokens forwarded to upstream APIs.
- Harden dynamic client registration before scale-up Do not treat DCR as anonymous self-service. Add verification flows, IP reputation checks, and risk-based controls before allowing broad registration.
Key takeaways
- Remote MCP deployments turn authorization into a delegated access problem that depends on issuer control, audience binding, and discovery metadata, not just login flows.
- The specification's separation of resource server and authorization server reduces trust concentration and makes governance boundaries easier to defend.
- Teams that implement MCP should prioritise external authorization, mandatory PKCE, and strict token validation before exposing remote tool access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP remote access depends on secure delegated authentication and issuer trust. |
| NHI-05 — Overprivileged NHI | MCP tool scopes and token forwarding can expand access beyond intended boundaries. | |
| Recommendation — Use NHI-04 to validate OAuth flows, issuer trust, and client authentication for MCP clients. Apply NHI-05 to constrain MCP tool scopes and prevent token reuse across upstream services. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centres on token handling, issuance, and lifecycle safeguards for delegated access. |
| IA-9 — Service Authentication | MCP servers and upstream APIs authenticate as services and must validate token audience correctly. | |
| Recommendation — Apply IA-5 to govern token issuance, validation, rotation, and revocation for MCP integrations. Use IA-9 to verify service-to-service token audience, issuer, and trust boundaries in MCP flows. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about how tool access and delegated authorization are governed. |
| Recommendation — Map MCP tool permissions to PR.AA-05 so entitlements are explicit, scoped, and auditable. | ||
Key terms
- Protected Resource Metadata: Protected resource metadata is machine-readable discovery data published by a service so clients can find its authorization expectations. For agent registration, it tells the actor where to look for supported flows and how to discover the trust model without relying on ad hoc integration.
- Dynamic Client Registration: Dynamic client registration is a protocol pattern that allows a software client to register itself with an authorization system automatically. For AI agents, it can reduce manual setup, but it also creates new identities at speed, which makes ownership, policy checks, and revocation essential.
- Resource Indicator: A resource indicator is a request-time signal in OAuth that tells the authorization server which resource server the token is meant for. In practice, it helps constrain the resulting token audience so access is tied to one API or logical service instead of being broadly reusable.
- Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org