OAuth dynamic client registration for AI agents
Dynamic client registration (RFC 7591) lets an AI client register itself with your OAuth server at runtime, so a person can connect Claude, ChatGPT, Cursor or any other MCP client to your product in one click, without you issuing a client ID to each app by hand. It matters for agents because there are hundreds of MCP clients, and no vendor can pre-register them all. The 2026-07-28 MCP spec deprecates it in favour of client ID metadata documents (CIMD), but keeps it for servers that don't support CIMD yet.
From our data: As of 3 Nov 2026, 68 of the 214 software vendors in our rankings advertise a registration endpoint behind their MCP server: Amplitude, Prismic, Notion, Supabase, beehiiv, Katana, Clerk and WorkOS. In our 1,846-company benchmark (11 Oct 2026), 14% did.
How an MCP client finds and joins your OAuth server
The client calls your MCP server
With no token, the server answers 401 and a WWW-Authenticate header pointing at its protected-resource metadata.
It reads /.well-known/oauth-protected-resource
This RFC 9728 document names the authorization server for that resource.
It reads /.well-known/oauth-authorization-server
This RFC 8414 document lists the authorize, token and registration endpoints.
It registers itself
It POSTs its name and redirect URIs to the registration endpoint and gets a client ID back.
The person signs in
A normal OAuth authorization-code flow with PKCE. The agent gets a scoped token; the person never touched an API key.
The replacement: client ID metadata documents
With CIMD, the client's ID is an HTTPS URL it controls, pointing at a JSON document that describes it (name, redirect URIs). Your authorization server fetches that document when the client shows up, instead of storing a registration. Advertise support with client_id_metadata_document_supported in your server metadata.
The 2026-07-28 MCP spec says clients and servers should support CIMD and may use dynamic client registration, which is now deprecated. Supporting both today covers new and older clients.
Vendors with OAuth self-registration on their MCP server
68 of the vendors in our rankings, from our scan on 3 Nov 2026.
Check it yourself
A registration_endpoint means clients can register with RFC 7591; client_id_metadata_document_supported: true means CIMD works. If the file is missing, also try /.well-known/openid-configuration, and check the authorization server named in your /.well-known/oauth-protected-resource.
curl -s https://example.com/.well-known/oauth-authorization-server | grep -oE '"(registration_endpoint|client_id_metadata_document_supported)":[^,}]*'
Questions
Is open client registration a security risk?
It lets anyone create a client, not get access. Every token still needs a person to sign in and approve scopes. Rate-limit registrations, show the client's name on the consent screen and expire unused clients.
Do I need RFC 9728 and RFC 8414 too?
Yes, in practice. They are how a client discovers where to register and sign in, starting from nothing but your MCP server's URL.
Is dynamic client registration deprecated?
In MCP, yes: the 2026-07-28 spec deprecates it in favour of client ID metadata documents and keeps it only for backward compatibility. Deprecated features stay in the spec for at least 12 months.
Does this replace API keys?
For people connecting assistants, yes. Keep API keys for server-to-server use and scripts.