Dynamic Client Registration (DCR) for MCP is the OAuth 2.0 extension defined in RFC 7591 that lets MCP clients register themselves with an authorization server at runtime, without manual setup. Traditional OAuth flows require developers to log into a provider dashboard, create an app, and copy a client_id and client_secret. That model breaks for MCP because MCP clients are diverse, numerous, and often installed by end users who never touch the provider’s dashboard. DCR fixes the friction. The client sends a registration request, the authorization server returns a fresh client_id, and the OAuth flow begins. The November 2025 MCP spec update made Client ID Metadata Documents (CIMD) the default identity mechanism for new MCP deployments, with DCR remaining as a fallback.
How Dynamic Client Registration Works in MCP
The MCP client discovers the authorization server through Protected Resource Metadata. It then sends a POST request to the registration endpoint with metadata about itself: client name, redirect URIs, allowed grant types, scope requests, and software statement (if signed). The authorization server validates the request, issues a unique client_id, and returns a registration response that includes the client_id and (optionally) a client_secret. The client stores these for the lifetime of the connection. From that point forward, the registered client follows the normal OAuth 2.1 authorization code flow with PKCE.
Certified MCP Security Expert
Attack, defend, and pen test MCP servers in 30+ hands-on labs. Get certified.
Why DCR Created New Security Risks for MCP
DCR’s openness is also its biggest weakness. Anyone can register a client with the authorization server, including attackers running phishing campaigns who register a client_id and redirect URI under their control. Obsidian Security found one-click account-takeover vulnerabilities in production MCP servers that ran as OAuth proxies, with failures around state parameter binding and consent enforcement. The MCP November 2025 update introduced CIMD precisely because DCR alone was being abused. CIMD relies on infrastructure-asserted identity instead of self-registration, closing most of the attack vectors that hit early DCR-only deployments.
How to Use DCR Safely in MCP
If you support DCR, require a signed software statement from a trusted source. Apply strict rate limits on the registration endpoint to stop registration-flooding attacks. Validate redirect URIs against an allowlist before accepting registration. Use short client_secret lifetimes for registered clients. Migrate to CIMD as the default for new deployments and treat DCR as a fallback. Log every registration event.
Summary
Dynamic Client Registration lets MCP clients self-register with authorization servers at runtime, removing the manual setup friction that would block consumer adoption. But DCR’s openness has caused real account takeover incidents, which is why CIMD is now the preferred default. The Certified MCP Security Expert (CMCPSE) certification trains engineers to harden DCR endpoints and migrate safely to modern identity-assertion patterns.