{"slug": "mcp-client-registration-dinner-party-or-nightclub", "title": "MCP Client Registration: Dinner Party or Nightclub?", "summary": "The Model Context Protocol (MCP) specification offers two client registration options for remote MCP servers: pre-registration, akin to a dinner party where clients are known in advance, and automated registration, akin to a nightclub where clients are verified on the spot. The choice depends on whether users are known and comfortable with setup overhead or need to connect to unknown servers dynamically, as explained in a technical post on MCP authentication flows.", "body_md": "Would you rather be invited by name to a dinner party or head to a club where the only thing between you and the thumping beat is the bouncer checking your ID?\n\nThe Model Context Protocol (MCP) offers client registration options analogous to both. The right answer to this question depends on your users. At the end of this post, you'll know the right solution for you.\n\nBut let's take a step back before we dig into client registration and discuss the entire authentication flow for remote MCP servers.\n\nAn MCP client like chatgpt.com or Claude desktop needs to get an access token to interact with an MCP server. But how does the authorization server know to trust an MCP client in the first place?\n\n## MCP Servers Are OAuth Resource Servers[#](#mcp-servers-are-oauth-resource-servers)\n\nAn MCP server doesn't authenticate users; it inspects access tokens and decides what the token permits, then takes action from there. The MCP client such as Claude.ai, Claude Code, or whatever you're using, securely holds that token and presents it to the MCP server. Every MCP client that connects to an MCP server using the HTTP based transport is an OAuth client, whereas not every OAuth client is an MCP client.\n\nAn MCP client can act on its own, with its own identity and authority, with no user involved. Consider an agent workflow that wakes up weekly, pulls files from Google Drive, and drops a summary in slack. This is the Client Credentials grant, and is covered by an [MCP extension](https://modelcontextprotocol.io/extensions/auth/oauth-client-credentials). The client authenticates as itself and acts on its own authority.\n\nThe more common case, outlined in the main part of the specification, has the MCP client acting on a user's behalf. Suppose you're letting Claude.ai read your Google Drive and email you a summary. The client is asking for delegated access to *your* resources. The correct flow here is the Authorization Code grant, with user consent captured.\n\n## How The Authorization Server Knows Who The Client Is[#](#how-the-authorization-server-knows-who-the-client-is)\n\nEnough preface, let's get back to the dinner party and the club.\n\nTraditional OAuth assumed a client was registered before any flow started. A developer registers an app with a central authority, the authorization server. The app has a client ID and possibly a client secret. The authorization server recognizes application code because it presents these credentials. In identity circles, the client ID and secret are obtained \"out of band\", because the exchange took place in some undefined fashion, possibly including human interaction, and didn't happen as part of an OAuth flow. This is static client registration. It works fine when you have an existing relationship with your users and they're comfortable with the setup overhead, but it doesn't scale to unknown clients and requires human coordination out of band.\n\nThis is the dinner party, where any client is known before the person logging in is ever on the scene.\n\nThis is called [pre-registration](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#pre-registration) in the MCP specification and is a supported option.\n\nBut MCP can also bust the assumption that clients are always known. Users point tools at MCP servers they've never interacted with. Agents determine what they need on the fly and find the MCP server that can supply what they want. In this world, you are unlikely to pre-register every possible MCP client against every authorization server it might encounter.\n\nIn this situation, you need a bouncer so that MCP clients can get into an MCP server club they've never visited before. Sure, there's some level of security, but it's a lot easier and quicker for a bouncer to check a couple of things on an ID than to hand out special invitations to people you know for a dinner party.\n\nYou need automated client registration. There are two options for this:\n\n- Client ID Metadata Document (CIMD)\n- Dynamic Client Registration (DCR)\n\nCIMD is the future. It works both for human delegation and agentic identity scenarios. It requires no prior relationship, and is where the ecosystem is headed.\n\nDCR is legacy. Use it only if you have existing clients that require it and a plan to migrate within the year.\n\nAutomated registration is becoming more and more common. It's what MCP servers with a wide, heterogenous set of MCP clients should use.\n\nLet's take a look deeper at both CIMD and DCR.\n\n## Client ID Metadata Documents[#](#client-id-metadata-documents)\n\nClient ID Metadata Documents (CIMD) is [the newer spec](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/). It is still navigating through the IETF working group as of this writing, but the MCP specification recommends it.\n\nAn MCP client presents a URL to the authorization server. That URL *is* the client ID. The JSON document hosted at that URL contains the configuration data the authorization server needs to register the client.\n\nTrust is bootstrapped off TLS. The client is asserting its identity through its domain and certificate, not through prior enrollment or human interaction. There's usually no secret; these are for the most part public clients and therefore [PKCE](https://datatracker.ietf.org/doc/html/rfc7636) is required.\n\nThis raises an obvious concern: aren't you just letting any client that can set up a JSON document at a URL demand registration at your authorization server? Not quite.\n\nThe spec doesn't require authorization servers to accept every client with a valid document at a URL. From section 8.9 of the -02 version:\n\nThe authorization server may choose to have its own heuristics and policies around the trust of domain names used as client IDs.\n\nWhat does this mean in practice? An authorization server can do things like:\n\n- enforce domain allowlists\n- reject URLs that don't match approved patterns\n- add additional consent screens\n- deny domains that had been recently registered\n\nThe spec defines the mechanism of limiting clients. The authorization server supplies the capability. The authorization server admins write the policy.\n\nIf you're building something new today and need automatic client registration, prefer CIMD. If you are building an MCP system, review the MCP clients you want to support. If CIMD is supported by all of them, use it\n\nIf CIMD isn't supported, then you have another choice before you fall back to pre-registration. Let's talk about the other option.\n\n## Dynamic Client Registration[#](#dynamic-client-registration)\n\nDynamic Client Registration (DCR) is the older option. [RFC 7591](https://datatracker.ietf.org/doc/html/rfc7591) was published in 2015 and solved the same problem, which was how to allow access to authorization servers without pre-registration. At that time, mobile applications were the client of choice. In my experience, this standard didn't see wide adoption at the time.\n\nDCR was used in earlier MCP specifications. As of the [July 2026 MCP specification release](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#dynamic-client-registration), DCR is formally deprecated and:\n\nremains available for backwards compatibility with authorization servers that do not support Client ID Metadata Documents\n\nMCP allows for a full year before anything deprecated is removed, so you have time to transition to CIMD. But the spec is explicit: don't use DCR unless you have existing MCP clients that require it. I wouldn't start anything new on DCR. The ecosystem has made its choice.\n\n## Public Clients And PKCE[#](#public-clients-and-pkce)\n\nAs mentioned above, many MCP clients are public OAuth clients. Desktop apps, browser tools, and mobile apps can't hold a client secret safely. Even web applications may choose to interact with authorization servers like public clients. PKCE is what makes the auth code exchange safe when there's no client secret. For public MCP clients, it's not optional.\n\nIf a client can store keys safely and perform asymmetric cryptography, the private key JWT authentication method gives you a stronger guarantee in the client-to-authorization-server handshake. Support for `private_key_jwt` is relatively uncommon in the MCP world right now, but I expect it to improve over time.\n\n## Where Is The Security?[#](#where-is-the-security)\n\nWhen I first heard about automatic OAuth client registration, I was a bit worried. After all, the out-of-band OAuth client registration I was used to provides an additional layer of security.\n\nBut as I've read and built more, I understand the multiple levels that help secure MCP servers, even with OAuth clients being automatically added.\n\nThe first is that MCP servers declare the authorization servers from which they will accept access tokens. From the [July 2026 specification](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/authorization-server-discovery):\n\nMCP servers MUST implement the OAuth 2.0 Protected Resource Metadata (RFC9728) specification to indicate the locations of authorization servers.\n\nIn addition to the authorization servers whose tokens they'll accept, MCP servers pick the scopes they want. The authorization server should prompt the users to consent to these scopes so the minted token includes them. The MCP server has a lot of control over the authorization process to begin with.\n\nThen, as mentioned above, the authorization server can have various checks and rules for which clients can register using CIMD.\n\nFinally, there are the per-user security layers, assuming the common use case where an MCP client is acting on behalf of a human:\n\n- the user authentication and consent process; even though [OAuth doesn't define how authentication happens](/articles/oauth/why-no-authentication-in-oauth) , it still happens\n- if and when a refresh grant occurs, the authorization server can refuse it if the user account has been abused or the account is no longer valid\n\nThese all layer together to offer security even if it is possible to register clients without any human effort or review.\n\n## CIMD Evolving[#](#cimd-evolving)\n\nThe CIMD specification is still evolving. While the MCP specification references the `00` version, a `02` version was published in July. The [CIMD GitHub repo](https://github.com/oauth-wg/draft-ietf-oauth-client-id-metadata-document/issues) has 40+ open issues at the time of writing. But the authors of CIMD are involved with the MCP project, therefore I expect that any major CIMD changes will be closely tracked by MCP.\n\n## Choosing The Right Registration Approach[#](#choosing-the-right-registration-approach)\n\nThe right approach is determined by who's using your MCP server.\n\nConsumer or SMB audience: people who'll type in an MCP server URL and expect things to work. Automatic client registration is the only sensible option. They're not pre-registering anything. Review the clients you want to support. If you just want to support the main players, Anthropic/Claude and OpenAI/ChatGPT, CIMD is supported by both. I was unable to find an authoritative source for CIMD/DCR support across many clients, so the best thing to do is survey users, find the clients they use and then review the relevant MCP client documentation.\n\nDeveloper audience: technically sophisticated users comfortable with OAuth tooling. Pre-registration is workable. You put client configuration in your developer portal; they register it in their MCP client. More friction, but friction developers can accept.\n\nEmployees in the enterprise: employees and corporate hierarchies have requirements that change the calculus entirely. There's an [enterprise-managed access extension to MCP](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization) explicitly designed for this, and if you are a large enterprise rolling MCP out to your internal employees, use that.\n\n[CIMD support](https://github.com/FusionAuth/fusionauth-issues/issues/3230) is coming soon to FusionAuth. Want to chat about how we see MCP being used in the wild, learn what the upgrade process will be like, or be notified when CIMD lands? [Reach out and chat](/contact).", "url": "https://wpnews.pro/news/mcp-client-registration-dinner-party-or-nightclub", "canonical_source": "https://fusionauth.io/blog/cimd-vs-dcr", "published_at": "2026-09-08 22:37:38+00:00", "updated_at": "2026-09-08 23:04:14.900763+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure"], "entities": ["Model Context Protocol", "OAuth", "Claude.ai", "Claude Code", "Google Drive", "Slack"], "alternates": {"html": "https://wpnews.pro/news/mcp-client-registration-dinner-party-or-nightclub", "markdown": "https://wpnews.pro/news/mcp-client-registration-dinner-party-or-nightclub.md", "text": "https://wpnews.pro/news/mcp-client-registration-dinner-party-or-nightclub.txt", "jsonld": "https://wpnews.pro/news/mcp-client-registration-dinner-party-or-nightclub.jsonld"}}