TL;DR: MCP’s 2025-11-25 spec shifts client registration toward Client ID Metadata Documents, which let OAuth clients identify themselves with a stable URL instead of a per-server registration flow, according to WorkOS. The change reduces client sprawl and registration-endpoint abuse, but it also makes domain trust, redirect-URI validation, and metadata-fetch controls central to identity governance.
At a glance
What this is: This technical guide compares DCR and CIMD for MCP client registration and concludes that URL-based client identity is becoming the default pattern.
Why it matters: IAM and platform teams need to understand how MCP registration changes shift control from registration endpoints to domain ownership, redirect validation, and metadata retrieval policy.
Context
MCP client registration is the process that lets an OAuth client tell an authorization server who it is and where responses should be sent. In MCP environments, that problem becomes harder because AI apps, IDE helpers, and agents may connect to many servers that were never pre-registered together.
The article’s core governance issue is not just registration convenience. It is how identity is established, validated, and replayed across distributed MCP interactions, where client metadata, redirect URIs, and fetch controls become part of the trust boundary.
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: How should security teams govern URL-based OAuth client identities in MCP?
A: Treat each CIMD URL as a governed non-human identity, not just a protocol field. Track ownership, allowed redirect URIs, metadata change history, and revocation paths, then apply policy before scopes are granted. A valid client_id proves domain control, but it does not prove the client should receive sensitive access.
Q: How should security teams stop client impersonation in CIMD flows?
A: Enforce exact matching between the request redirect_uri and the allowlist published in the metadata document, and reject any authorization request that tries to send the code to an unlisted callback. That check prevents a false client from receiving the user’s authorization response.
Q: Should organisations keep DCR if CIMD is the new default?
A: Yes, but only for closed ecosystems where administrators need explicit server-side approval or the client cannot host stable web metadata. In open MCP deployments, CIMD is the cleaner default because it avoids registration sprawl and removes the public registration endpoint.
Technical breakdown
Why DCR created registration sprawl in MCP
Dynamic Client Registration lets a client POST its metadata to an authorization server at runtime and receive a minted client_id, sometimes with a secret. That works when client counts are modest, but MCP changes the scale assumptions: one client may touch thousands of servers, and each server may accumulate a growing registry of auto-created entries. The security cost is not only operational clutter. A public registration endpoint becomes an abuse surface for spam registrations, denial of service, and malformed metadata. Lifecycle governance also weakens because re-registration can become a broken recovery pattern rather than an exception.
Practical implication: Treat runtime client registration as an identity lifecycle problem, not just an onboarding feature.
How CIMD uses a URL as the client identity
Client ID Metadata Documents replace the registration ceremony with a stable HTTPS URL that points to a JSON document describing the client. The authorization server fetches that document, checks that the client_id matches the URL, and validates fields such as redirect_uris, grant_types, token_endpoint_auth_method, and optional jwks_uri. In practice, the model shifts trust from a server-side registry to a domain-hosted identity record. That makes metadata integrity, HTTPS enforcement, cache behaviour, and exact redirect matching part of the security boundary. The identity is no longer minted per server; it is asserted through control of the publishing domain.
Practical implication: Validate client metadata fetches as if they were authentication inputs, not passive configuration reads.
Why CIMD reduces one class of risk while introducing another
CIMD removes the public registration endpoint, which reduces registration abuse and client-secret sprawl. But it also causes the auth server to fetch attacker-supplied URLs, which creates SSRF exposure if private IP ranges, redirects, or oversized responses are not constrained. The model therefore moves the control point from client enrollment to metadata retrieval. Redirect-URI validation also becomes the key anti-impersonation check, because the server must compare the request against the allowed redirect_uris in the fetched document before issuing codes. The trust model is narrower than reputation: domain ownership proves control of a web origin, not that the client should be trusted by default.
Practical implication: Harden metadata fetch policy and redirect-URI validation before adopting URL-based client identity at scale.
Threat narrative
Attacker objective: The attacker’s objective is to obtain an authorization code or tokens by impersonating a legitimate MCP client and steering responses to an attacker-controlled domain.
- Entry occurs when a malicious or misconfigured client submits a URL-style client_id that points the authorization server at attacker-controlled metadata.
- Credential and authorisation abuse is blocked only if the server correctly fetches the metadata document and enforces exact redirect-URI matching against the published allowlist.
- Impact is avoided when no authorization code is delivered to the attacker-controlled redirect URI, preventing token theft or client impersonation.
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 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
URL-based client identity is a governance upgrade, not a trust guarantee: CIMD removes the registration endpoint bottleneck, but it does not solve client trust by itself. It simply moves the trust decision to domain ownership, metadata integrity, and redirect validation. For identity teams, that means the control plane shifts from who may register to what the server is allowed to fetch and accept.
Metadata retrieval is now part of the authentication boundary: In CIMD, the authorization server is no longer reading static client records it created earlier. It is dereferencing a live web object supplied by the client, which means HTTPS enforcement, redirect blocking, response-size limits, and cache discipline become first-order identity controls. That is a governance change, not a cosmetic protocol change.
Client registration lifecycle becomes identity lifecycle: DCR created per-server client state and the burden of cleanup, rotation, and re-registration. CIMD flattens that state, but the lifecycle problem does not disappear. It shifts into hosting discipline, domain control, and the operational reliability of the metadata document. Practitioners should stop thinking in terms of per-server client inventory and start thinking in terms of durable client identity publication.
Registration sprawl is the symptom, not the disease: The article’s deeper signal is that MCP clients behave like non-human identities with cross-environment reach, so conventional OAuth assumptions break under scale. The field is moving toward identity that is portable, web-native, and cacheable, which means governance has to focus on provenance, runtime validation, and metadata source assurance rather than manual enrolment alone.
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: MCP Security Guide
What this signals
Client metadata retrieval is becoming the new identity perimeter: MCP shifts the control point from registration forms to fetched documents, so teams need to govern how client_id URLs are validated, cached, and refreshed. That is a different operating model from traditional OAuth onboarding, and it makes metadata provenance part of the trust decision.
The practical lesson for identity programmes is that non-human identities now need durable, web-native identity publication rules, not just enrolment workflows. When a client identity is expressed as a URL, the organisation must govern who controls the domain, who can change the document, and how server-side trust is re-evaluated over time.
For practitioners
- Harden client metadata fetch policy Block loopback and private IP ranges, enforce HTTPS only, set short timeouts, cap response size, and refuse redirects into private networks when fetching CIMD documents.
- Validate redirect URI allowlists strictly Require the redirect_uri in each authorization request to match the published redirect_uris exactly, and reject flows that try to send codes to any unlisted callback location.
- Treat client_id URLs as governed identity records Inventory which MCP clients publish metadata at stable domains, review who controls those domains, and define how changes to the document are approved and monitored.
- Reserve DCR for closed ecosystems only Use dynamic registration only where admins need a server-side registry, because open MCP environments will otherwise accumulate client sprawl and unmanaged registration endpoints.
Key takeaways
- CIMD moves MCP client identity from per-server registration to a stable URL-backed document, which reduces registration sprawl but raises the importance of provenance and validation.
- The key security boundary is no longer the signup flow alone. It is the server’s ability to fetch, cache, and verify client metadata without trusting attacker-controlled infrastructure.
- Practitioners should treat client metadata documents as governed identity records and enforce strict redirect matching before they let OAuth code flows proceed.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | CIMD and DCR both govern how MCP clients authenticate their identity to servers. |
| NHI-05 — Overprivileged NHI | MCP clients can accumulate broad access and per-server state if registration is uncontrolled. | |
| NHI-07 — Long-Lived Secrets | DCR can create per-server secrets and persistent client state that CIMD is intended to reduce. | |
| Recommendation — Apply NHI-04 to validate how MCP clients prove identity before token issuance. Use NHI-05 to scope each MCP client to only the servers and permissions it actually needs. Use NHI-07 to minimise persistent client secrets and prefer short-lived or key-based authentication. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth client credentials and metadata-driven trust depend on managed authenticators and rotation. |
| Recommendation — Apply IA-5 to control client credential issuance, rotation, and revocation for MCP integrations. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | OAuth token theft and client impersonation map to credential abuse paths relevant to this article. |
| Recommendation — Map abused MCP client registrations to credential access and lateral movement detections. | ||
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.
- 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.
- Redirect URI: A redirect URI is the endpoint where an authorization server sends the user back after a login or consent step. In secure OAuth implementations, it must be pre-registered and matched exactly so an attacker cannot divert the response to a malicious destination.
- Metadata Fetch Hardening: Metadata fetch hardening is the set of controls that make server-side retrieval of untrusted client documents safe. It includes network restrictions, response size limits, timeouts, and caching, so the fetch process cannot be abused for SSRF, resource exhaustion, or trust bypass.
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 June 7, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org