What is a Client ID Metadata Document in MCP's OAuth profile?
answer
- the URL is the identifier
- no registration call happens
- authorization server fetches your metadata
- https URL with a path
- client_id_metadata_document_supported
basics
~20 sA Client ID Metadata Document lets an MCP client use an HTTPS URL with a path as its client_id. The authorization server dereferences that URL to read the client's metadata — client_name, redirect_uris — with no prior registration.
solid answer
~40 sIn MCP revision 2026-07-28, a Client ID Metadata Document (CIMD) is how a client with no prior relationship to an authorization server obtains a usable `client_id`. Rather than registering and being issued an opaque identifier, the client publishes a JSON metadata document at an HTTPS URL that includes a path, and presents **that URL itself** as its `client_id`. When the authorization request arrives, the authorization server fetches the URL and uses the document the way it would use a registration record: `client_name` for the consent screen, `redirect_uris` to validate the callback that was requested. Support is advertised by the authorization server as `client_id_metadata_document_supported`, and a client must check that before attempting CIMD. The document is self-asserted, so everything in it is an unverified claim on which the authorization server layers its own trust policy.
code
json · 4 lines{
"client_name": "Example MCP Host",
"redirect_uris": ["https://app.example.com/oauth/callback"]
}go deeper
Know the one-line shape: the client publishes a metadata document at an HTTPS URL and uses that URL as its client_id, so no registration step is needed.
Be ready to walk the mechanics: the URL carries a path, the authorization server fetches and parses it, and reads client_name and redirect_uris from it. Mention that support is advertised as client_id_metadata_document_supported.
Show that you know the document is self-asserted. Explain what it actually proves (control of the URL), why the consent screen should display the URL rather than the display name, and how caching and URL availability affect a live authorization path.
Own the tradeoff: CIMD buys registration-free onboarding for an open ecosystem at the cost of unvetted client identity. Be able to say where you would still demand pre-registration — high-privilege scopes, first-party clients — and how you would express that policy.
## The problem CIMD solves A remote MCP server is an OAuth 2.1 resource server, so a client that wants to call it must first get an access token from the authorization server that server points at. Classic OAuth assumes the client is a known entity: a human creates a registration record at the authorization server ahead of time and receives a `client_id` (and often a secret). That assumption breaks in MCP. A user can add an arbitrary remote MCP server to their host application at any moment, and the client software has never met that server's authorization server, has no account there, and cannot wait for a human to fill in a form. Something has to produce a `client_id` on the spot. ## What a Client ID Metadata Document is CIMD collapses the identifier and the metadata into one thing. The client publishes a JSON document of client metadata at an HTTPS URL that includes a path — something like `https://app.example.com/oauth/client-metadata.json` — and uses that exact URL as its `client_id` in the authorization request. There is no registration call and no credential handed back. The authorization server dereferences the URL, parses the document, and treats it as the client's record for this request: `client_name` is what it can display to the user, `redirect_uris` is the list it validates the requested callback against. The important shift is where the metadata lives. Under registration, the authorization server stores a copy. Under CIMD, the client hosts it and the authorization server reads it, typically caching for a while rather than storing a permanent record. ## Discovering support Not every authorization server accepts a URL as a `client_id`. In MCP's profile the authorization server advertises the capability in its metadata as `client_id_metadata_document_supported`, and a client must verify that flag before proceeding down this path. If the flag is absent, CIMD is not an option and the client moves on to the next registration approach available to it. ## Why a URL, and why a path Using an HTTPS URL as an identifier gives three properties at once. It is globally unique with no coordination — nobody has to allocate identifiers. It is self-describing — the authorization server (and the user looking at a consent screen) can see the domain that is asking. And it is resolvable — the metadata is fetched from the same place the identifier names, so there is no separate lookup table to keep in sync. MCP requires the URL to carry a path rather than being a bare origin. An identifier that is only an origin names a whole host rather than a particular client, which makes it impossible for one host to publish several distinct clients and blurs which document the authorization server is meant to read. ## Self-asserted means untrusted The only thing CIMD proves is control of the URL — that is, control of the DNS name and a valid TLS certificate for it. Nothing in the document is vetted. `client_name` can claim to be any well-known product. A well-designed authorization server therefore shows the `client_id` URL on the consent screen rather than only the display name, and applies its own policy on top: allowlists or denylists, scope ceilings for unknown clients, tighter token lifetimes, or requiring pre-registration for the most privileged scopes. The same reasoning explains why the client cannot treat CIMD as a credential. There is no client secret involved; the document is public by construction, so anything sensitive must never appear in it. ## Operational consequences Because the document is fetched, its availability is now part of the authorization path: if the URL cannot be resolved, the authorization server has no `redirect_uris` list to validate against and the request cannot proceed. Authorization servers cache the document, which means changes to it are not instantaneous, and it also means a user's earlier approval may have been based on a version of the document that has since changed. Clients should treat the document as long-lived and stable, publishing a new URL for a materially different client rather than silently rewriting an existing one. ## Where it sits in 2026-07-28 CIMD is the preferred way to get a `client_id` when nothing was arranged in advance. RFC 7591 dynamic client registration, which used to fill that gap, is deprecated in MCP revision 2026-07-28 and retained only for backwards compatibility with authorization servers that support nothing else. A client that already has an out-of-band, pre-registered `client_id` for a given authorization server should keep using it — CIMD exists for the case where no such arrangement exists.
- Why must the CIMD client_id URL include a path instead of being a bare origin?An origin names a host, not a client. Requiring a path means the identifier points at one specific metadata document, so a single host can publish several distinct clients and the authorization server knows exactly which document to fetch. It also keeps one client on a domain from implicitly speaking for everything else hosted there.
- What stops an attacker from publishing a CIMD whose client_name copies a well-known product?Nothing at the protocol level — the document is self-asserted and only proves control of the URL. The defence is on the authorization server side: display the client_id URL itself, not just the name, so the user sees the actual domain, and back that with allowlists, denylists or scope limits for clients that have never been vetted.
- What happens to an authorization request if the CIMD URL cannot be fetched?The authorization server has no metadata, so it cannot validate the requested redirect URI or name the client on a consent screen, and the request cannot safely proceed. That makes hosting availability part of your auth path; servers usually cache the document with a TTL, which softens brief outages but does not remove the dependency.
saying these in an interview costs you the question
- Says CIMD is just dynamic registration with a URL
- Thinks the authorization server verifies who published the document
- Uses a bare https origin as the client_id
- Assumes every authorization server accepts CIMD without checking
- Treats client_name in the document as verified identity