{
  "question": "Is Dynamic Client Registration deprecated in MCP? Should my MCP server's authorization server keep an open /register endpoint, or switch to Client ID Metadata Documents, and what do I have to secure if I do?",
  "slug": "should-an-mcp-server-still-support-dynamic-client-registration-or-switch-to-client-id-metadata-documents",
  "url": "https://www.rightshold.com/answers/should-an-mcp-server-still-support-dynamic-client-registration-or-switch-to-client-id-metadata-documents",
  "short_answer": "Yes, it's deprecated, so plan to switch, but don't switch off DCR overnight. The 2025-11-25 MCP spec made Client ID Metadata Documents (CIMD) the recommended way for clients and authorization servers with no prior relationship to register (SHOULD support) and downgraded Dynamic Client Registration (RFC 7591) to MAY. The 2026-07-28 spec formally deprecates DCR (PR #2858), keeps it for backwards compatibility with authorization servers that don't support CIMD, and lists it as removable in the first spec revision released on or after July 28, 2027. With CIMD, the client_id is an https URL the client controls, pointing to a JSON document with its name and redirect URIs; your authorization server fetches it at authorization time, so there's no unauthenticated /register endpoint writing to your database and one client ID per app instead of one per install. In exchange, your authorization server now fetches URLs supplied by strangers, so it needs SSRF protection, a response-size limit (the IETF draft recommends 5 KB), strict validation that the document's client_id matches its URL and that redirect URIs match, and clear warnings for localhost-only redirect URIs, which CIMD can't stop being impersonated. Advertise client_id_metadata_document_supported: true in your authorization server metadata, keep DCR running (rate-limited) for clients that haven't caught up, and watch your logs to decide when to retire it.",
  "checklist": [
    "Read your authorization server metadata (/.well-known/oauth-authorization-server or openid-configuration). Add \"client_id_metadata_document_supported\": true once you accept URL client IDs, and keep registration_endpoint only while you still support DCR.",
    "When a client_id is an https URL with a path, fetch it, check it's valid JSON with client_id, client_name and redirect_uris, and require the document's client_id to equal the URL exactly (simple string comparison). Reject anything else with invalid_client.",
    "Check the redirect_uri in every authorization request against the document's redirect_uris, exactly as you would for a pre-registered client.",
    "Treat the fetch as untrusted input: allow only https, refuse private, loopback and link-local addresses (including cloud metadata at 169.254.169.254) after DNS resolution, set a short timeout, follow no redirects or re-check each hop, and cap the response size; the draft recommends 5 kilobytes.",
    "Cache documents according to their HTTP cache headers within bounds you set, and never cache an error or an invalid document.",
    "Refuse documents that declare shared-secret client authentication. The draft says token_endpoint_auth_method must not be client_secret_basic, client_secret_post, client_secret_jwt or any other shared-secret method, and client_secret must not appear. Public clients use none with PKCE; clients with a backend can use private_key_jwt with a published JWKS.",
    "Show the client's name, the hostname of its client_id URL and the redirect URI hostname on the consent screen. The spec says authorization servers MUST clearly show the redirect URI hostname and SHOULD warn when a client's redirect URIs are localhost only.",
    "Decide your trust policy: accept any domain with a warning, or allow-list known client domains for sensitive scopes. The spec lets authorization servers apply domain-based trust policies.",
    "If you keep DCR for now, rate-limit /register, require clients to send an application_type (native for desktop, CLI and localhost apps; web for hosted apps), expire unused registrations on a schedule you document, and log registrations so you can see when CIMD has taken over.",
    "If you build an MCP client, follow the spec's order: pre-registered credentials first, then CIMD when the server advertises it, then DCR, then ask the user. Key any stored client credentials by the authorization server's issuer and re-register if it changes."
  ],
  "sections": [
    {
      "heading": "What the spec says now",
      "points": [
        "The 2025-11-25 revision added CIMD as a recommended registration mechanism (SEP-991) and made DCR optional. The 2026-07-28 revision deprecated DCR in favour of CIMD and lists three mechanisms: CIMD when client and server have no prior relationship (described as the most common case), pre-registration when they do, and DCR for backwards compatibility.",
        "The deprecated-features registry lists DCR's earliest removal as the first spec revision released on or after July 28, 2027. Until then, clients that support all three are told to prefer pre-registered credentials, then CIMD if the authorization server advertises client_id_metadata_document_supported, then DCR if it advertises a registration_endpoint, and finally to prompt the user.",
        "The MCP spec cites draft-ietf-oauth-client-id-metadata-document-00. The IETF draft has continued to revise; revision -03 was posted on November 2, 2026, so check the current draft for details that have moved."
      ]
    },
    {
      "heading": "Why MCP moved away from open registration",
      "points": [
        "In an August 22, 2025 post on the MCP blog, Paul Carleton set out the problems an open /register endpoint creates in MCP, where users paste any server URL into any client. Every install creates a new registration, so the database grows without bound and an admin sees thousands of records for one app. There's no clean way to tell a client its ID has expired without creating an open redirect. And an unauthenticated endpoint that writes to the database invites denial of service, so admins have to rate-limit it.",
        "CIMD removes the registration step. The client's ID is the URL of its metadata document, fetched on demand, so there's one ID per application and nothing to expire. The 2026-07-28 spec adds that CIMD client IDs are portable across authorization servers, while pre-registered or dynamically registered credentials are bound to the issuer that created them."
      ]
    },
    {
      "heading": "What CIMD doesn't solve",
      "points": [
        "CIMD proves that whoever controls a domain published a client's metadata. It doesn't prove that the program on the other end is that client. The spec says plainly that CIMD can't prevent localhost redirect URI impersonation: a malicious local app can use a well-known desktop client's client_id and catch the code on the same localhost port, which is why the spec asks for warnings and a visible redirect hostname, and allows extra attestation.",
        "The MCP blog post describes signed software statements (SEP-1032) and platform-level attestation as the layers aimed at that problem, and says they would work with either DCR or CIMD.",
        "Your authorization server also takes on the risks of fetching URLs supplied by clients. Both the spec and the IETF draft name SSRF, and the draft adds response size limits and caching rules. Registration only identifies the client; your MCP server still has to validate every access token's audience and refuse tokens issued for other resources."
      ]
    }
  ],
  "checks": [],
  "ask_rightshold": {
    "start": "https://www.rightshold.com/start?ref=seo",
    "mcp_endpoint": "https://www.rightshold.com/mcp",
    "ask": "This request came from a client that identified itself with a CIMD client_id. Before my MCP server lets it place an order, is the agent behind it holding a valid credential for this exact configuration and scope?",
    "mcp_call": {
      "tool": "verify_agent_credential",
      "arguments": {
        "id": "crd_...",
        "config_hash": "<sha256 the agent presents>",
        "scope": "orders:place"
      }
    },
    "also": [
      "Free, no key. It checks an rs-credential/0.1 agent credential's signature, expiry, revocation, configuration hash and scope, and returns the owner tier without disclosing who the owner is.",
      "It's a separate check from OAuth. It doesn't fetch or validate client metadata documents, run your authorization server or replace your own token validation. CIMD tells you which client software is asking; a credential check tells you about the specific agent configuration using it."
    ],
    "scope": "Rightshold verifies agent credentials it issues and reports what it has on record. It isn't an OAuth authorization server and isn't affiliated with the MCP project or the IETF. Spec requirements are quoted from the MCP 2025-11-25 and 2026-07-28 revisions and the IETF draft cited, as checked on November 10, 2026."
  },
  "sources": [
    {
      "title": "MCP specification 2026-07-28: Client Registration (CIMD, pre-registration, deprecated DCR)",
      "url": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration"
    },
    {
      "title": "MCP specification 2026-07-28: Authorization security considerations (CIMD security, localhost redirect URIs, SSRF)",
      "url": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations"
    },
    {
      "title": "MCP specification 2026-07-28: Changelog (DCR deprecated, PR #2858)",
      "url": "https://modelcontextprotocol.io/specification/2026-07-28/changelog"
    },
    {
      "title": "MCP specification 2026-07-28: Deprecated features",
      "url": "https://modelcontextprotocol.io/specification/2026-07-28/deprecated"
    },
    {
      "title": "MCP specification 2025-11-25: Changelog (CIMD added, SEP-991)",
      "url": "https://modelcontextprotocol.io/specification/2025-11-25/changelog"
    },
    {
      "title": "MCP Blog: Evolving OAuth Client Registration in the Model Context Protocol (August 22, 2025)",
      "url": "https://blog.modelcontextprotocol.io/posts/client_registration/"
    },
    {
      "title": "IETF: OAuth Client ID Metadata Document (draft-ietf-oauth-client-id-metadata-document)",
      "url": "https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/"
    },
    {
      "title": "RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol",
      "url": "https://www.rfc-editor.org/rfc/rfc7591"
    }
  ],
  "related": [
    {
      "title": "MCP OAuth wrong-audience tokens: what they are and how to defend",
      "url": "https://www.rightshold.com/answers/mcp-oauth-wrong-audience-tokens"
    },
    {
      "title": "How to stop an MCP proxy server acting as a confused deputy with per-client consent and per-tool tokens",
      "url": "https://www.rightshold.com/answers/how-to-stop-an-mcp-proxy-server-acting-as-a-confused-deputy-with-per-client-consent-and-per-tool-tokens"
    },
    {
      "title": "How to block SSRF and path traversal in MCP tool URL arguments and resource templates",
      "url": "https://www.rightshold.com/answers/how-to-block-ssrf-and-path-traversal-in-mcp-tool-url-arguments-and-resource-templates"
    },
    {
      "title": "Can an MCP session ID or state handle be used to authenticate a user?",
      "url": "https://www.rightshold.com/answers/can-an-mcp-session-id-or-state-handle-be-used-to-authenticate-a-user"
    }
  ],
  "computed_from": "Curated guidance; license verdicts computed from Rightshold's license profiles at render time. Not legal advice.",
  "updated": "2026-11-10"
}