What is dynamic client registration?

Dynamic client registration, explained#

Classic OAuth assumes the app's developer registered it in advance: they open the provider's developer console, type a name and a redirect URL, and copy a client ID into their code. That is fine when there are a few well-known integrations. It breaks down when any of thousands of AI clients might connect to any of thousands of servers, with no prior relationship between them.

With dynamic registration, the client finds the registration_endpoint in the authorization server's metadata (RFC 8414) and sends a JSON document with fields such as client_name, redirect_uris, grant_types and token_endpoint_auth_method. The server validates it and answers with a client_id, and for confidential clients a secret. The client then runs the normal authorization code flow with that ID.

Servers that allow open registration must assume anyone can register. Consent screens should show the client's name and redirect host clearly, redirect URIs should be checked exactly, and registrations should carry no special trust.

In MCP, dynamic registration came first and is still widely supported. The 2025-11-25 specification added OAuth Client ID Metadata Documents as the recommended approach: the client ID is itself an HTTPS URL pointing at a JSON document describing the client, so the server can fetch it instead of storing a registration. Dynamic registration remains an optional fallback for compatibility.

For example, a person adds a new MCP server to their editor. The editor reads the server's metadata, sees a registration endpoint, posts {"client_name":"My Editor","redirect_uris":["http://127.0.0.1:33418/callback"]}, receives a client ID, and immediately opens the consent screen. The person never knew a registration happened.