Dynamic client registration in MCP: where it still breaks

At a glance

What this is: WorkOS breaks down why Dynamic Client Registration exists in MCP and why the same bootstrap mechanism still exposes trust, redirect, and lifecycle failures as deployments scale.

Why it matters: IAM and NHI teams need to see that MCP onboarding is an authorization problem, not just a protocol convenience, because registration choices shape impersonation risk, token leakage, and long-lived client state.

Context

Dynamic Client Registration in MCP is the OAuth onboarding pattern that lets an unknown client register itself, receive a client_id, and begin the normal authorization code flow without prior manual setup. The security question is not whether that works, but which trust assumptions it shifts from provisioning time to runtime.

In an MCP environment, that matters because clients are discovered dynamically and can be short-lived, user-facing, or both. The article shows why the protocol initially leaned on self-registration, and why the newer CIMD default changes the governance burden rather than eliminating it.

For identity programmes, the practical issue is that client onboarding, redirect validation, and lifecycle control become part of the access model. That places MCP squarely in the intersection of OAuth, NHI governance, and runtime authorization policy.

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 does dynamic client registration create more governance work at scale?

A: Because every successful registration creates a persistent client record, even when the client is short-lived or experimental. That means identity teams must manage ownership, revocation, update policy, and stale registrations as lifecycle tasks. The more MCP clients you support, the more DCR behaves like a client directory service that needs explicit governance.

Q: How should security teams reduce redirect URI abuse in MCP onboarding?

A: Use exact-match validation wherever possible, and treat localhost callbacks, custom schemes, and broad patterns as exceptions rather than defaults. Redirect URIs are where authorization codes land, so loose validation can turn self-registration into token theft. The safest approach is to narrow accepted patterns to what your deployment truly needs.

Q: What is the difference between DCR and CIMD in MCP governance?

A: DCR lets the client register itself with the authorization server and creates server-side state, while CIMD shifts much of that discovery burden to pre-published metadata. DCR is useful when a server must accept unknown clients at runtime, but CIMD reduces registration state and narrows trust decisions. The choice is really between self-registration and pre-declared client identity.

Technical breakdown

How DCR bootstraps OAuth clients in MCP

Dynamic Client Registration lets a client POST its metadata to a registration endpoint and receive a client_id, and sometimes a secret or registration token, before starting the standard OAuth authorization code flow. In MCP, that solves the problem of unknown clients arriving at runtime and needing a trusted identifier before they can request tokens. The authorization server still has to validate redirect URIs, grant types, response types, and token endpoint authentication mode. The mechanism is simple, but it turns the registration endpoint into part of the access-control surface, not a passive setup step.

Practical implication: Treat client registration as an authorization control point, not as a convenience API.

Why redirect URI validation becomes a security boundary

Redirect URIs define where the authorization server is allowed to send the user back after consent. With DCR, the client declares those URIs at registration time, so the server must decide whether they are safe enough to trust before any code is issued. MCP increases the complexity because local callbacks, custom schemes, and ephemeral ports are all common, and each expands the chance that validation rules are too permissive. If the validation layer allows broad matches, wildcard patterns, or unsafe localhost assumptions, the registration process can become a token theft path rather than a safety control.

Practical implication: Constrain redirect URI acceptance tightly and review every exception as if it were a token-leakage control.

Why DCR creates state and lifecycle sprawl

Every successful DCR request creates a persistent client record, even when the client itself is short-lived. That means the authorization server inherits inventory, update, revocation, and stale-record problems that scale with every registration. In a many-to-many MCP ecosystem, a single tool can re-register repeatedly across versions, forks, and environments, which makes client metadata drift likely. CIMD shifts some of that burden away from server-side storage, but DCR still remains where dynamic onboarding is unavoidable or where policy needs to be enforced at registration time.

Practical implication: Build a lifecycle model for registered clients before DCR becomes your default intake path.

Threat narrative

Attacker objective: The objective is to obtain OAuth-backed MCP access through a self-registered or impersonated client that the user and server both treat as legitimate.

1. Entry occurs when an attacker or unwanted client reaches an advertised DCR endpoint and self-registers with metadata that appears acceptable to the authorization server.
2. Credential access occurs after a legitimate OAuth login is induced through a trusted-looking client name or redirect path, allowing authorization codes to be issued under false pretences.
3. Escalation follows when permissive redirect validation, weak brand trust signals, or broad registration rules let the attacker convert the registration into token-bearing access.
4. Impact is the ability to use those tokens against MCP resources while the authorization server treats the spoofed client as a valid registered application.

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

Dynamic onboarding breaks the assumption that OAuth clients are known before trust is granted: DCR was designed for a world where clients could introduce themselves at runtime and still be treated as valid application actors. That assumption fails when the client identity is user-facing, rapidly created, or easy to spoof, because the registration event becomes part of the attack surface. The implication is that identity governance for MCP cannot treat registration as clerical setup; it is an access decision.

Redirect URI trust is a control, not a convenience field: The article shows that redirect URIs are the most important safety boundary in DCR because they determine where authorization codes and tokens can land. That boundary is fragile in MCP because localhost callbacks, custom schemes, and ephemeral ports are normal. The practical conclusion is that runtime onboarding and safe redirect enforcement have to be governed together.

Persistent registration state turns ephemeral clients into lifecycle debt: Each DCR success creates an enduring record that must be reviewed, rotated, revoked, or retired later. That is a governance burden many identity programmes do not model explicitly, especially when the client itself may only exist for one task or one version. The implication is that MCP client governance needs joiner-mover-leaver thinking for software actors, not just for people.

Client impersonation is the named concept that explains why DCR remains brittle at scale: A self-asserted client name can create trust before the server has any durable proof of who is behind the registration. That is not a bug in OAuth alone; it is the expected outcome of applying static trust assumptions to dynamic client discovery. Practitioners should read this as a warning that identity proofing and registration policy have to precede token issuance, not follow it.

CIMD changes the default, but it does not erase the governance problem DCR exposed: Moving away from server-side registration reduces state pressure, yet environments that still allow DCR retain all the old trust decisions at the boundary. The article therefore signals a category split between systems that can afford pre-published metadata and those that still need self-registration. Practitioners should plan for both operating models rather than assuming one will replace the other everywhere.

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 impersonation is the core governance gap: DCR assumes that a valid registration request is close enough to a trustworthy client, but MCP environments make that assumption fragile because names, logos, and redirect metadata are easy to copy. The control point is not the token exchange alone, but the boundary where the client first claims identity.

Dynamic client registration needs lifecycle thinking, not just protocol support: Every registration adds another asset to inventory, another redirect URI to review, and another revocation path to test. If your programme does not govern software actors the way it governs people, DCR will accumulate hidden access long after the original use case is gone.

For practitioners

• Tighten registration policy at the DCR boundary Allow only the redirect URIs, grant types, and response types that your MCP environment actually supports, and reject everything else by default.
• Constrain redirect URI handling Prefer exact-match redirect URIs and treat localhost, custom schemes, and broad wildcard patterns as exceptions that require explicit review.
• Build client lifecycle governance Track every registered client as a governed asset, with ownership, review cadence, revocation rules, and retirement criteria for stale records.
• Add trust signals before registration approval Use allowlists, signed metadata, or other brand verification steps when self-asserted client names are not enough to distinguish legitimate clients.

Key takeaways

• Dynamic Client Registration helps MCP clients onboard without prior setup, but it also shifts identity trust into a runtime registration step that is easy to abuse.
• The article shows that client impersonation, redirect URI misuse, and registration state sprawl are the three governance failures that matter most.
• For identity teams, the practical response is tighter registration policy, stricter redirect validation, and explicit lifecycle governance for registered clients.

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.
• Client identity impersonation: Client identity impersonation occurs when an attacker convinces a system that a malicious client is a trusted one. In machine and agent environments, this often happens through weak registration controls, poor metadata validation, or trust placed in identifiers that were never strongly bound to a real authority.

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.