Skip to content

Dynamic Client Registration (for MCP)

OAuth 2.0 mechanism (RFC 7591) letting clients register themselves with an authorization server on the fly — no human admin, no pre-configured client ID. Critical for the MCP world because agents discover and connect to arbitrary MCP servers at runtime.

The MCP flow Auth0 implemented

  1. Protected-resource metadata — MCP server exposes a /.well-known/... endpoint advertising supported scopes and the authorization server.
  2. Authorization-server metadata — client fetches more info (endpoints, additional scopes, flow details).
  3. Dynamic registration — client POSTs to the registration endpoint and gets back a client ID + secret just for this session.
  4. PKCE authorization code flow — standard OAuth flow, client gets an access token with the requested scopes.
  5. Access to MCP tools — the access token is presented to the MCP server; middleware verifies JWT + scopes before exposing tools.

Why it matters

Without DCR, connecting an agent (or Claude Code, or MCP Inspector, or ChatGPT via the App SDK) to a new MCP server requires manual admin setup. With DCR, any authorized-by-policy client can register itself — same flow, different client identities, all subject to the server's scope/capability model.

Open DCR caveat

Galan: "Open DCR is a thing — but there are concerns about how this will scale." Fully open registration means any entity can get a client ID. Current guidance: DCR-with-policy (authorization-server decides whether to accept a registration) rather than fully-open. Client ID Metadata (next OAuth spec) will add more trust-binding options.

Supported MCP clients (early 2026, Auth0)

  • MCP Inspector (the canonical dev tool)
  • Claude Code (via claude mcp add in terminal — has open issue around scope specification)
  • OpenAI ChatGPT App SDK (integration starting to work, some configuration needed)
  • Any client that implements the current MCP OAuth spec

Cross-references