Dynamic client registration in MCP: where it still breaks

At a glance

What this is: Dynamic Client Registration in MCP is the OAuth bootstrap mechanism for unknown clients, and the article shows where its flexibility creates security and operational pressure.

Why it matters: It matters because MCP onboarding is now an identity problem, not just an integration problem, and IAM teams need controls that work for transient NHI-style clients as well as human-facing auth flows.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read WorkOS's guide to Dynamic Client Registration in MCP

Context

Dynamic Client Registration is the OAuth pattern that lets an unknown client introduce itself to an authorization server at runtime and obtain a client_id without manual pre-registration. In MCP, that matters because the client base is no longer a small set of known applications; it is a fast-moving mix of desktop tools, IDEs, local agents, and runtime integrations that need onboarding to work without human coordination.

The security gap is not the registration call itself, but the assumption that a self-asserted client identity is trustworthy enough to receive durable OAuth treatment. Once dynamic onboarding becomes the default, identity teams need to decide how much trust can be attached to redirect URIs, metadata, and self-declared client names before a token is ever issued.

The article’s central point is pragmatic: DCR still has a place where clients cannot publish stable metadata, but it becomes risky when used as a blanket answer for every MCP environment. That makes this a governance question for NHI, workload identity, and emerging agentic access patterns, not just a protocol choice.

Key questions

Q: What breaks when Dynamic Client Registration is used without tight MCP controls?

A: The main failure is trust leakage through self-asserted metadata. If registration accepts broad redirect URIs or weak client constraints, a malicious client can impersonate a legitimate tool, capture authorization responses, or create durable records that outlive the intended trust window. The control gap is not OAuth itself, but allowing registration to define trust too loosely.

Q: Why do MCP environments make DCR harder to govern than traditional OAuth apps?

A: MCP multiplies the number of clients, servers, and runtime onboarding events, so registration is no longer a rare administrative task. That creates more opportunities for impersonation, more persistent client records to maintain, and more variation in redirect URI handling. The governance challenge is scale, not novelty.

Q: How can security teams know whether DCR is creating hidden lifecycle risk?

A: Look for stale client records, duplicate registrations, inconsistent redirect URI patterns, and registrations that never appear in review or revocation workflows. If the authorization server has more live client entries than operationally justified, DCR has become a lifecycle management problem rather than a bootstrap mechanism.

Q: Who is accountable when a dynamically registered MCP client is abused?

A: Accountability usually sits with the organization operating the authorization server, because it chose the registration rules, validation thresholds, and revocation process. If the environment lets self-asserted clients create durable access without ownership tracking, the failure is governance design, not just user misuse.

Technical breakdown

How DCR bootstraps MCP OAuth

Dynamic Client Registration is the pre-authentication step that creates a client record before the normal authorization code flow begins. The client fetches server metadata, learns whether a registration endpoint exists, submits redirect URIs and grant settings, and receives a client_id if the server accepts the request. In MCP, this is the mechanism that turns unknown clients into first-class OAuth apps without a dashboard workflow. The design assumes the server can validate metadata well enough to trust the resulting registration, even though the client may be transient or previously unseen.

Practical implication: treat registration metadata as part of the trust boundary, not as administrative paperwork.

Redirect URI validation and client impersonation

DCR shifts the core OAuth safety problem to redirect URI validation. If a server accepts broad localhost patterns, wildcards, or loose custom schemes, a malicious client can register a believable name and route authorization codes to an unsafe endpoint. In MCP, where clients are often user-facing, that creates a consent-screen deception problem as well as a token leakage problem. The issue is not only who can register, but whether the server can constrain where the auth response is allowed to go.

Practical implication: enforce exact, narrow redirect URI rules and do not rely on self-asserted client names for trust.

State sprawl and lifecycle drift at scale

Every successful DCR request creates durable server-side state, even when the client is short-lived or rarely reused. At MCP scale, that becomes a client directory problem: stale registrations accumulate, metadata drifts, update rules vary across clients, and the authorization server inherits cleanup obligations it may not be designed to manage. The operational issue is not merely volume. It is that dynamic onboarding creates identity records whose lifetime often outlasts the practical need for them, which complicates auditability and revocation.

Practical implication: design explicit registration expiry, revocation, and review rules before enabling wide DCR support.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Self-asserted client identity is the governing assumption DCR depends on, and that assumption becomes fragile as MCP scales. DCR works because the authorization server accepts a client’s own metadata as a starting point for trust. That is manageable in narrow environments, but it becomes structurally weak when every new client can arrive at runtime with little or no prior relationship. The practical conclusion is that identity governance for MCP cannot treat registration as a neutral onboarding step.

Dynamic onboarding turns OAuth client management into an NHI lifecycle problem. The article shows that each registration creates durable state, yet many of those clients are transient, duplicated, or never revisited. That is the same lifecycle pressure identity teams already see with service accounts and API keys: assets appear quickly, live longer than intended, and drift away from the conditions under which they were trusted. The implication is that registration, revocation, and review must be governed as one lifecycle.

Redirect URI control is the named concept that exposes the real failure mode: trust leakage through registration metadata. DCR does not fail because OAuth is broken, it fails when the server treats self-declared metadata as sufficiently bounded without proving that the response destination is safe. This is a governance gap, not a protocol bug. Practitioners should read it as a reminder that the attack surface lives in the metadata the client is allowed to declare.

Client registration sprawl: MCP environments can accumulate large numbers of stale or duplicated registrations because every onboarding event creates persistent server state. That sprawl weakens audit confidence, inflates review workload, and makes revocation harder to reason about. The implication is that lifecycle ownership must be explicit before dynamic registration is widely enabled.

Unknown client bootstrap changes the trust model for agentic access. Even when a client is not fully autonomous, it behaves like a non-human identity once it registers and requests tokens on demand. That means teams need a governance model that spans MCP clients, service accounts, and other machine identities instead of handling them as separate exceptions. The implication is that identity architecture should be converging, not fragmenting, around runtime-issued trust.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably inventory the machine identities that dynamic onboarding creates.
• For a broader control baseline, see NHI Lifecycle Management Guide for provisioning, rotation, offboarding, and review patterns that apply to dynamic client populations.

What this signals

Client registration sprawl: MCP onboarding makes identity records proliferate faster than many programmes can review them, so the operational challenge is now inventory quality as much as authentication policy. Teams that already struggle with service account visibility will feel the same pressure here, because dynamic clients create the same persistence problem in a different form.

The next governance step is to treat MCP clients as machine identities with lifecycle obligations, not as disposable integration artifacts. That means tying registration, revocation, and review into the same control plane, and aligning the process with the NHI Lifecycle Management Guide rather than improvising one-off exception handling.

For teams mapping this to broader standards, OAuth registration policy should sit alongside zero trust thinking, because the server is deciding how much trust to extend before the client has established durable credibility. The practical move is to build registration controls that are strict enough to survive runtime onboarding, not just initial approval.

For practitioners

• Tighten registration metadata policy Allow only MCP-safe combinations such as authorization_code, code responses, and token_endpoint_auth_method set to none for public clients, and reject unknown or risky fields by default. Keep the allowed metadata small enough that registration cannot be used to smuggle in unsafe OAuth behavior.
• Constrain redirect URI patterns Prefer exact-match HTTPS redirect URIs where possible, and if localhost or custom schemes are required, limit them to specific hosts, ports, and path prefixes. Treat wildcard matching as a control failure unless the environment has a clearly documented exception process.
• Add lifecycle controls for dynamic registrations Define when a client registration expires, who can revoke it, and how stale entries are reviewed. Pair registration records with periodic inventory checks so the authorization server does not become an unmanaged directory of obsolete MCP clients.
• Require PKCE everywhere DCR is used Enforce PKCE on authorize and token exchange, and reject any registration or token request that does not prove possession of the verifier. This is the minimum protection when clients are public and registration happens without manual vetting.

Key takeaways

• Dynamic Client Registration solves MCP bootstrap friction, but it also turns client onboarding into an identity governance decision.
• The biggest risks are self-asserted trust, redirect URI abuse, and persistent registration sprawl that outlives the client itself.
• Teams should govern DCR as part of NHI lifecycle management, with strict metadata rules, PKCE enforcement, and explicit revocation.

Key terms

• Dynamic Client Registration: Dynamic Client Registration is the OAuth mechanism that lets a client create its own registration record at runtime instead of being preloaded by an administrator. In MCP, it acts as the bootstrap step for unknown clients, but it also makes trust, metadata validation, and lifecycle management part of the authorization server’s security boundary.
• Redirect URI: A redirect URI is the destination an authorization server is allowed to send the user back to after login or consent. In dynamic registration, it becomes one of the most important trust controls because the server is accepting the client’s declared response locations before access is issued.
• Client lifecycle: Client lifecycle is the set of controls that governs how a registered identity is created, reviewed, updated, and removed. For MCP and other non-human identities, lifecycle discipline is essential because runtime onboarding can produce long-lived records that no longer match the original trust conditions.
• Public client: A public client is an OAuth client that cannot safely hold a secret and therefore relies on other protections such as PKCE. In MCP environments this usually describes desktop tools, local apps, and similar software where registration and token exchange must be secured without shared credentials.

Deepen your knowledge

Dynamic Client Registration and MCP onboarding are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building policy for transient clients or machine identities, it is worth exploring.

This post draws on content published by WorkOS: Dynamic Client Registration in MCP, what it is, why it exists, and when to still use it. Read the original.