Dynamic client registration in MCP: are your controls ready?

TL;DR: Dynamic Client Registration gives MCP clients a just-in-time way to register with OAuth servers, but it also creates client impersonation risk, redirect URI abuse, and state sprawl at scale, according to WorkOS. The governance problem is that dynamic onboarding exposes trust assumptions in authorization that many identity programmes were built to treat as static.

NHIMG editorial — based on content published by WorkOS: Dynamic Client Registration in MCP, what it is, why it exists, and when to still use it

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.

Questions worth separating out

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

A: The main failure is trust leakage through self-asserted metadata.

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.

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.

Practitioner guidance

• 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.
• 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.
• Add lifecycle controls for dynamic registrations Define when a client registration expires, who can revoke it, and how stale entries are reviewed.

What's in the full article

WorkOS's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step OAuth metadata exchange and registration request examples for MCP clients.
• Concrete guidance on when CIMD is a better default than DCR in public web and local client environments.
• Implementation notes for redirect URI policy, PKCE handling, and registration endpoint hardening.
• WorkOS-specific configuration details for enabling DCR in AuthKit.

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

Dynamic client registration in MCP: are your controls ready?

Explore further

View Full Forum →  |  NHI Foundation Course →