Notifications
Clear all
Topic starter
23/06/2026 9:10 pm
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
25/06/2026 2:18 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Dynamic client registration in MCP: where it still breaks
