Dynamic Client Registration
Dynamic Client Registration (DCR).
Dynamic Client Registration (RFC 7591) lets an OAuth client register itself at runtime by POSTing its metadata to an authorization server's registration endpoint and receiving a client_id back.
DCR solved a real problem: an OAuth client could not talk to a server it had never been configured for. For AI agents and MCP clients, that is the default case. Early MCP authorization specs therefore relied on it.
The weakness is that open registration accepts anyone. Each registration produces a fresh client record with self-asserted metadata, and the server has no stable way to recognize the same software next time. Servers end up rate-limiting or gating the registration endpoint, which defeats the purpose.
The MCP authorization specification dated 2025-11-25 demoted DCR to a backwards-compatibility option and made Client ID Metadata Documents the preferred path. If you run an MCP server's authorization server today, support CIMD first and keep DCR only for older clients. The MCP server identity model guide covers the rest of the MCP authorization requirements.
DCR still matters outside MCP. OIDC relying parties use it to register settings such as subject_type, which is how an RP asks for a pairwise or ephemeral subject identifier.
Common questions
What is OAuth Dynamic Client Registration?
It is the RFC 7591 mechanism that lets an OAuth client register with an authorization server at runtime. The client POSTs its metadata to the registration endpoint, and the server creates a client record and returns a client_id.
Does MCP still use Dynamic Client Registration?
Only as a fallback. The MCP authorization specification dated 2025-11-25 says servers and clients MAY support DCR for backwards compatibility. Clients try a pre-registered client first, then CIMD if the server advertises client_id_metadata_document_supported, then DCR, then prompting the user.
Why did MCP move from DCR to CIMD?
DCR creates a new client record for every registration, and the server learns nothing durable about who the software is. CIMD uses an HTTPS URL as the client_id, so the client's identity is tied to a domain and the server does not have to store a growing list of anonymous clients.
How does a client find the registration endpoint?
The authorization server advertises registration_endpoint in its metadata. An MCP client only falls back to DCR when that endpoint is present and neither a pre-registered client nor CIMD is available.
Related terms
In the guides
AI Agent Identity and MCP: Authenticating Non-Human Identities
How CIAM evolves for AI agents in 2026: MCP, OAuth 2.1 Dynamic Client Registration, scoped agent tokens, and patterns separating agent from human identity.
Authentication for AI Agents: OAuth Patterns for Non-Human Identity
How AI agents authenticate in 2026. The on-behalf-of pattern, delegated agent identity, OAuth 2.1 Dynamic Client Registration, and where the patterns are still being invented.
MCP Server Identity Model: Authentication, Authorization, and Trust for the Model Context Protocol
MCP is OAuth 2.1 with discovery. How MCP clients identify themselves (CIMD first, DCR as fallback), how servers scope access, and what the spec leaves to you.