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.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Dynamic Client Registration (DCR) in MCP: What it is, why it exists, and when to still use it”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 2:18 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Dynamic client registration in MCP: where it still breaks