MCP client auth discovery now avoids DCR security holes

At a glance

What this is: This article explains how MCP clients discover an authorization server without dynamic registration, and why the newer metadata-based model removes major security weaknesses.

Why it matters: It matters because IAM teams now have to govern MCP as a real identity integration pattern, not a demo-friendly shortcut, with direct implications for NHI, delegated access, and auditability.

By the numbers:

• The June 2025 spec revision introduced Protected Resource Metadata (RFC 9728).
• The November 2025 spec revision introduced Client ID Metadata Document (CIMD), which flips the trust model entirely.

👉 Read WorkOS's analysis of MCP auth discovery and client registration risks

Context

MCP client authentication became a governance problem the moment the protocol moved beyond manual configuration. Once clients had to discover where to authenticate, the security question shifted from connectivity to trust, and that is where dynamic client registration exposed the weakest assumptions in early deployments.

For identity teams, MCP sits at the intersection of workload identity, delegated authorization, and secret handling. The protocol is not just about agent or app connectivity. It is about whether an external client can prove who it is without forcing the authorization server to trust unsolicited registration requests or arbitrary metadata.

The shift from open registration to metadata discovery is a familiar identity pattern: reduce the number of trust-bearing entry points, make identity assertions observable, and move verification to a place where governance can actually see it. In MCP environments, that distinction is the difference between scalable federation and a public registration surface.

Key questions

Q: What breaks when MCP clients use dynamic registration in production?

A: Dynamic registration breaks the assumption that the authorization server only interacts with trusted clients. In production, it creates a public onboarding surface that can be abused for registration floods, SSRF, and client impersonation. The safest response is to treat DCR as a legacy compatibility path, not the default trust model for MCP.

Q: Why do MCP discovery flows change the identity governance model?

A: MCP discovery changes governance because the server must declare where clients authenticate instead of relying on ad hoc configuration. That moves the problem from manual setup to controlled verification, which is easier to audit and less exposed to arbitrary self-registration. IAM teams should treat discovery as part of the trust boundary, not a convenience layer.

Q: How do security teams know whether MCP client onboarding is too permissive?

A: Onboarding is too permissive when unknown clients can register, supply arbitrary metadata URLs, or obtain credentials before a meaningful trust check. Those signals indicate the protocol is accepting identity claims too early. A better pattern is server-declared discovery with client verification through controlled metadata.

Q: Should organisations keep dynamic client registration enabled for older MCP clients?

A: Only as a tightly controlled exception. If older clients require DCR, isolate them, log all registrations, and limit where they can operate. New deployments should move to protected resource metadata or CIMD so the default architecture no longer depends on a public registration endpoint.

Technical breakdown

Why dynamic client registration created an identity control gap

Dynamic Client Registration let MCP clients register themselves with an authorization server, receive credentials, and then begin OAuth flows. In practice, that meant the server had to accept requests from unknown clients before it had a trust decision. The result was an identity control gap, not just an implementation choice. Open registration endpoints can be abused for mass registration, credential sprawl, and consent-screen impersonation because the server is forced to trust the registration path before it knows the actor.

Practical implication: treat open registration as a high-risk exception and remove it wherever a metadata-based discovery path exists.

How protected resource metadata changes MCP discovery

Protected Resource Metadata moves discovery away from client registration and onto the resource server. The MCP server exposes a well-known endpoint that tells clients which authorization server to use, then returns a standard OAuth challenge with a resource_metadata pointer when no valid token is present. This preserves interoperability without asking the resource server to mint or manage client identities. In identity terms, the server becomes a verifier, not a registration broker.

Practical implication: implement the well-known metadata endpoint and make token verification the only trust decision your MCP server performs.

Why CIMD removes the registration endpoint from the trust model

Client ID Metadata Document inverts the earlier model by making the client_id a URL that points to client-owned metadata. Instead of registering dynamically, the client proves identity by publishing a document at a location it controls, and the authorization server fetches that document to validate it. That eliminates the public registration surface and collapses a large portion of SSRF and client impersonation exposure. For enterprise identity, this is closer to controlled federation than ad hoc onboarding.

Practical implication: prefer CIMD for new MCP deployments so client identity is validated through controlled metadata, not live registration.

Threat narrative

Attacker objective: The objective is to turn an MCP authentication surface into a foothold for abuse, reconnaissance, and unauthorized token or client trust.

1. Entry occurred when the MCP design allowed unknown clients to reach a public registration endpoint and submit self-asserted metadata.
2. Credential access or abuse followed when attackers used that registration path to obtain client credentials or coerce the server into outbound metadata fetches.
3. Impact came from resource exhaustion, SSRF-enabled probing, and client impersonation that undermined trust in the authorization flow.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Dynamic client registration was built for onboarding, not for hostile internet exposure. The moment an MCP server lets unknown clients register themselves, it accepts an identity claim before it has any durable basis for trust. That assumption fails because attacker-controlled metadata turns registration into an attack surface, not a governance control. Practitioners should treat open registration as a broken premise in production MCP.

Protected resource metadata is the point where MCP stops behaving like an ad hoc integration and starts behaving like governed identity infrastructure. The trust decision moves from a stranger-facing registration flow to a server-declared authorization path, which is easier to audit and constrain. That is the right shape for NHI governance because it reduces who can speak first in the protocol.

Client ID Metadata Document is a named trust inversion, not just a convenience feature. By making the client assert identity through a document it hosts, CIMD removes the need for a public registration endpoint and cuts off an entire class of impersonation and SSRF abuse. The practitioner conclusion is simple: if your MCP deployment still depends on dynamic registration, you are preserving an identity assumption that the newer spec no longer needs.

MCP exposes a broader NHI governance lesson about discovery surfaces. Every time identity tooling asks an untrusted party to self-register, self-describe, or self-attest before verification, the control plane becomes softer than the data plane. The field is moving toward server-declared discovery and client-verifiable metadata because that is the only way to scale trust without scaling the attack surface.

Identity blast radius in MCP is driven by how much the server trusts before verification. The more the protocol tolerates unknown clients, arbitrary URLs, and registration-time credential issuance, the larger the blast radius becomes. That should push architects to re-evaluate onboarding design, not just token validation.

From our research:

• Most enterprise identity providers, including Okta, Azure AD, and Ping, disable DCR by default, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• The same research found that when AWS credentials are exposed publicly, attackers attempt access within 17 minutes on average, showing how quickly identity exposure turns into action.
• That is why teams should pair discovery redesign with the Guide to the Secret Sprawl Challenge and reduce any credential-bearing onboarding path before it becomes internet-reachable.

What this signals

Metadata-based discovery is becoming the default shape of governed machine identity. As MCP adoption grows, security teams should expect more pressure to replace client-driven onboarding with server-declared trust paths and controlled metadata validation. The broader lesson is that identity governance now has to cover protocol discovery, not just authentication endpoints.

With the AI Agents: The New Attack Surface report showing that 80% of organisations already report AI agents acting beyond intended scope, the governance gap is widening across both agentic and non-agentic workloads. MCP is one of the places where that pressure becomes visible first, because discovery and authorization are tightly coupled.

Identity blast radius: the total amount of trust a protocol grants before verification. In MCP environments, that blast radius shrinks when the server declares the auth path and the client proves identity through controlled metadata, which is exactly the direction IAM teams should prefer for new integrations.

For practitioners

• Remove public registration from production MCP paths Disable dynamic client registration wherever CIMD or protected resource metadata can satisfy the client discovery flow. Keep any backward-compatible registration path tightly scoped, monitored, and isolated from primary production tenants.
• Constrain metadata fetching to approved destinations If any discovery or validation flow fetches client-controlled URLs, restrict outbound requests, block metadata IP ranges, and log every fetch. This limits SSRF exposure from logo_uri, jwks_uri, sector_identifier_uri, and similar fields.
• Make authorization-server discovery explicit in the resource server Publish a well-known resource metadata endpoint and return a WWW-Authenticate challenge that points clients to the correct authorization server. That keeps the MCP server in a verification role instead of a registration role.
• Separate legacy compatibility from new trust models If older clients still require DCR, isolate them behind a compatibility tier and track them as exceptions. New MCP integrations should use CIMD so the identity model does not drift back toward open registration.

Key takeaways

• Dynamic client registration creates a public trust surface that is difficult to defend in production MCP deployments.
• Protected resource metadata and CIMD shift MCP toward verifiable discovery and away from self-asserted onboarding.
• IAM teams should treat MCP discovery as part of the identity control plane and retire open registration wherever possible.

Key terms

• Dynamic Client Registration: A protocol pattern where a client registers itself with an authorization server and receives credentials before it can authenticate. In MCP contexts, that convenience creates a public trust surface because unknown clients can self-assert identity and metadata before verification.
• Protected Resource Metadata: A discovery mechanism where the resource server tells clients which authorization server to use. It removes the need for the client to register first, which is safer for MCP because the server stays in a verification role instead of becoming an open onboarding endpoint.
• Client ID Metadata Document: A trust model where the client_id resolves to a metadata document hosted by the client itself. The authorization server fetches that document to validate identity, which replaces open registration with a verifiable assertion and materially reduces impersonation and SSRF exposure.
• Identity Blast Radius: The amount of trust a protocol grants before it has verified the actor. In MCP and other machine identity systems, the blast radius grows when onboarding accepts self-assertion or arbitrary URLs, and shrinks when discovery is server-declared and client-verifiable.

Deepen your knowledge

MCP client discovery, client registration risk, and workload identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI-connected services or federated workloads, it is worth exploring.

This post draws on content published by WorkOS: How MCP Clients Find Your Auth Server (Without You Telling Them). Read the original.