Dynamic Client Registration: the part of MCP OAuth almost nobody supports
Dynamic Client Registration (DCR), defined in RFC 7591, is an OAuth extension that lets a client register itself with an authorization server automatically, at connection time, by calling an API — instead of a human manually creating a client ID and secret ahead of time in a developer portal. For an MCP (Model Context Protocol) client connecting to a new MCP server, DCR is what makes it possible to go from “never seen this server before” to “have valid OAuth credentials for it” without a person ever touching a web console.
Why MCP requires it
Traditional OAuth integrations are set up once, by a developer, ahead of time: you go to Google’s or GitHub’s developer console, register an app, get back a client ID and secret, and hardcode them into your app. That works when your app talks to a small, known set of providers you can register with in advance.
MCP inverts that model. An MCP client — Claude, ChatGPT, or a custom agent framework — is built to connect to authorization servers it has never seen before, at runtime, discovered dynamically as the user adds new MCP servers. There is no human present at connection time to click through a vendor’s “create an OAuth app” flow, and no way for the client’s developer to have pre-registered with every MCP server that will ever exist. The MCP authorization spec builds on DCR specifically so a client can show up at an unfamiliar authorization server, call one endpoint, and get working credentials back — automatically, on the spot.
Why most OAuth providers don’t support it
Most established OAuth providers — Google, GitHub, classic Okta — were built around the pre-registration model and never needed to support DCR, because their client base has always been a relatively small number of apps registered ahead of time through a web console. Adding a client still means a human logging into a dashboard and filling out a form. That’s a reasonable design for a general-purpose identity provider, but it’s an architectural mismatch for MCP: it assumes exactly the kind of advance, human-driven setup that MCP’s dynamic, run-time discovery model is designed to avoid. This is also the practical reason so many MCP servers today ship with no auth at all, or fall back to a bare static API key — bolting on real OAuth without DCR support means either building a registration flow from scratch, or asking every user to manually create credentials before they can connect.
How mcpauth implements it
mcpauth implements RFC 7591 as a real, working endpoint: POST /api/oauth/register. An MCP client calls it with a JSON body describing itself, and gets back a spec-compliant client registration.
The request is authenticated with your project’s registration secret — the one you get from the mcpauth dashboard when you create a project for your MCP server — sent as a bearer token, and the body contains redirect_uris (required), plus optional client_name and token_endpoint_auth_method:
curl -X POST https://your-issuer.example.com/api/oauth/register \
-H "Authorization: Bearer <project registration secret>" \
-H "Content-Type: application/json" \
-d '{
"redirect_uris": ["https://client.example.com/callback"],
"client_name": "My MCP Client",
"token_endpoint_auth_method": "none"
}'The response returns a client_id (and a client_secret for confidential clients) that the MCP client can immediately use to start the OAuth 2.1 authorization flow at GET /oauth/authorize — no dashboard, no waiting, no human in the loop. mcpauth also publishes a discovery document at GET /.well-known/oauth-authorization-server (RFC 8414), so a client only needs your issuer URL to find the registration endpoint, along with every other endpoint it needs, on its own.
For the full endpoint reference, including request and response shapes for registration, authorization, token exchange, revocation, and introspection, see /docs/endpoints.
FAQ
What is RFC 7591?
RFC 7591 is the IETF standard for OAuth 2.0 Dynamic Client Registration. It defines a POST /register endpoint that lets a client submit its own metadata (redirect URIs, client name, token endpoint auth method) and receive a client_id — and a client_secret, if it's a confidential client — back in the response, all via a single API call instead of a human filling out a form in a developer portal.
Does an MCP client need DCR to connect?
Not always, but it's the default the MCP authorization spec is built around. If a client already knows a client_id — because a developer hardcoded one — it can skip registration. But general-purpose MCP clients (Claude, ChatGPT, agent frameworks) are designed to connect to authorization servers they've never seen before, so they lean on DCR to register themselves automatically the first time they see a new server, with no human in the loop.
Can I use mcpauth without DCR (e.g. with a manually configured client)?
Yes. POST /api/oauth/register is how clients get a client_id automatically, but nothing requires that path. You can create a client through other means and hardcode its client_id into a client integration, or skip client-facing OAuth entirely and use POST /api/oauth/token/exchange to mint tokens server-to-server for users your own backend already authenticated. DCR is the convenient default, not a requirement to use mcpauth.
What happens if my previous OAuth provider doesn't support DCR?
Every MCP client that hits your server has to be manually registered by a human before it can connect — someone has to go into a developer console, create an OAuth app, and paste a client_id back into the client's configuration. That works for a single internal integration, but it breaks down for a public MCP server, since you can't ask every person running Claude or another MCP client to go register an OAuth app with you before they can use your tools. That gap is exactly what mcpauth's /api/oauth/register endpoint exists to close.