MCP client auth discovery now avoids DCR security holes

At a glance

What this is: This article explains how MCP auth discovery evolved away from Dynamic Client Registration toward metadata-based discovery that closes registration abuse, SSRF, and impersonation paths.

Why it matters: It matters because MCP is becoming a common control plane for AI tool access, and identity teams need to govern discovery, client trust, and token validation without exposing open registration flows.

Context

MCP auth discovery is the process of letting a client find the correct authorization server without manual setup. In this case, the security problem is not authentication itself but the discovery path, because early MCP patterns used open client registration flows that expanded trust before identity was established.

For identity teams, the important shift is that discovery now sits inside the control boundary. Instead of treating registration as a convenience layer, practitioners have to decide whether the client is asserting identity through metadata or creating a new trust relationship through dynamic registration.

The article argues that the newer metadata-based approach is more suitable for enterprise use because it removes public registration endpoints and keeps the MCP server focused on token validation rather than onboarding unknown clients. That makes the problem squarely one of NHI governance and federation design rather than application plumbing.

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 client metadata URLs create SSRF risk in MCP onboarding?

A: Because the authorization server may fetch those URLs during client validation. If the URLs are attacker-controlled, the server can be pushed into probing internal services, reaching cloud metadata endpoints, or otherwise making arbitrary outbound requests. The risk comes from the server trusting a client-supplied location before identity is established.

Q: How should security teams decide between DCR and CIMD for agent registration?

A: Use DCR when clients are long-lived, curated, and manageable through a persistent registry. Use CIMD when the environment has frequent client churn, distributed discovery, or many agentic components that need on-demand identity publication. The decision should follow the client lifecycle and trust model, not vendor preference or implementation convenience.

Q: What governance controls should sit around MCP client discovery?

A: Teams should inventory approved clients, define who owns client metadata, and document how revocation works when a client changes or is retired. Discovery should be paired with lifecycle governance, otherwise the protocol can make it easy to start trust relationships that no one later knows how to end.

Technical breakdown

Why Dynamic Client Registration created an attack surface

Dynamic Client Registration lets a client register itself with an authorization server at runtime. In MCP, that meant an unauthenticated party could trigger new client creation, metadata fetching, and credential issuance before any stable trust relationship existed. The weaknesses are structural: registration endpoints invite abuse, metadata URLs can be weaponised for server-side requests, and identity claims such as client names can be spoofed in consent flows. In practice, DCR turns client onboarding into an externally reachable trust establishment step, which is a poor fit for enterprise identity boundaries.

Practical implication: Treat open client registration as an exposed trust boundary and do not rely on it for production MCP onboarding.

How protected resource metadata changes discovery

Protected Resource Metadata moves discovery out of registration and into declaration. The MCP server publishes a metadata document that points clients to the correct authorization server, typically via a well-known endpoint and a WWW-Authenticate challenge. That means the server no longer needs to accept new clients just so they can locate auth. Instead, clients learn where to authenticate from a resource-advertised location and then follow a standard OAuth flow. The architectural benefit is narrower trust: the server confirms token validity, while discovery simply tells the client where to begin.

Practical implication: Use resource metadata to publish the auth server location and keep onboarding out of the discovery path.

Why Client ID Metadata Documents remove the registration problem

Client ID Metadata Documents reverse the trust direction. The client publishes metadata at a URL it controls, and the authorization server fetches that document to verify identity. The client_id becomes the URL, which removes the need for a public registration endpoint and the credential exchange that came with DCR. This is important because the server now validates a claimed identity against a controlled metadata document rather than creating a new identity on demand. For MCP deployments, that makes client identity more auditable and less exposed to registration-flood and impersonation patterns.

Practical implication: Prefer CIMD when you need client identity verification without exposing dynamic registration to the internet.

Threat narrative

Attacker objective: The attacker wants to obtain or abuse client trust so they can reach downstream OAuth-controlled resources, probe internal services, or overwhelm the registration path.

1. Entry occurs when an attacker reaches an exposed Dynamic Client Registration endpoint and submits large volumes of fake or spoofed client requests.
2. Credential access follows when the flow allows the attacker to obtain client credentials or force the server to fetch attacker-controlled metadata URLs.
3. Escalation happens when those URLs are used for server-side request forgery, internal probing, or impersonation of trusted client names in consent screens.
4. Impact is either resource exhaustion, unauthorised token use, or a trust boundary that admits malicious MCP clients into the OAuth flow.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Registration-free discovery is now the right trust model for MCP. Early MCP patterns treated client onboarding as part of discovery, but that collapsed the line between locating an authorization server and admitting a new identity. Protected resource metadata and CIMD separate those functions, which is why they fit enterprise governance better than DCR does. Practitioners should treat discovery as declaration and registration as a different, much higher-risk trust decision.

Open client registration is a governance problem, not just a protocol feature. Once strangers can create clients, every downstream control becomes harder to reason about: audit scope expands, consent screens become spoofable, and lifecycle tracking turns noisy. That is not merely inconvenient. It undermines the ability to prove who owns a client, who approved it, and when it should be offboarded.

Ephemeral client trust needs explicit lifecycle boundaries. MCP authentication now looks cleaner, but the control point has moved. Identity teams still have to inventory which clients are allowed to assert themselves through metadata, which authorization servers they can reach, and how revocation works when client metadata changes. The implication is that federation design now matters as much as token verification.

Discovery trust debt: the hidden cost of letting protocol convenience create identity trust before verification. In MCP, that debt showed up as registration abuse, SSRF risk, and impersonation opportunities. The practitioner conclusion is simple: if discovery creates trust, the governance model is already too permissive.

MCP client authentication is now a federation problem with NHI consequences. The shift from DCR to metadata-based discovery means the organisation must govern which machines may speak for themselves, not just which humans approve them. That pushes the work into OWASP-NHI, federation controls, and lifecycle governance rather than product-specific implementation shortcuts. Teams should align MCP onboarding with established non-human identity policy, not ad hoc developer convenience.

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: Guide to the Secret Sprawl Challenge

What this signals

MCP discovery now exposes a familiar identity lesson: convenience features become governance liabilities when they establish trust before verification. The practical shift is to treat discovery as a published declaration, not an onboarding flow, and to align it with NHI lifecycle controls rather than developer ergonomics.

Discovery trust debt: when a protocol lets clients create trust relationships while locating the authorization server, it accumulates operational debt that later appears as impersonation, audit noise, and hard-to-contain registration abuse. Teams should recognise that debt early and move discovery behind explicit identity policy.

The scale of the problem is not theoretical. According to the State of Secrets Sprawl 2026, 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which reinforces how quickly MCP-adjacent identity surfaces can leak beyond intended control.

For practitioners

• Replace open registration with metadata-based discovery Use protected resource metadata to advertise the authorization server and reserve dynamic registration only for backward compatibility or tightly controlled exceptions.
• Restrict any remaining DCR endpoints If legacy clients still require dynamic registration, isolate the endpoint, add strict allowlists, and monitor for registration floods, spoofed client names, and unusual metadata URLs.
• Validate client identity through CIMD Require client metadata to come from a URL controlled by the client and review how metadata hosting, revocation, and ownership changes are governed over time.

Key takeaways

• MCP client discovery became safer when it stopped depending on strangers registering themselves before trust was established.
• The core security lesson is that discovery and onboarding are different identity problems, and conflating them creates registration abuse, impersonation risk, and SSRF exposure.
• Enterprises should prefer metadata-based discovery and reserve dynamic registration for tightly controlled legacy use cases.

Key terms

• 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.
• 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.
• 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.
• Integration Trust Debt: The accumulated risk created by long-lived, over-scoped, or forgotten SaaS connections that remain active after their original purpose fades. The debt grows when teams treat integration setup as a one-time task instead of a lifecycle-managed identity relationship.

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.