CIMD for MCP auth: what changes for identity teams?

TL;DR: Client ID Metadata Documents replace writable client registration with a URL-based, stateless identity model for MCP, letting authorization servers fetch and validate client metadata on demand while enforcing exact redirect URI matching and HTTPS-only client IDs, according to WorkOS. The shift makes client identity scale better, but it also moves trust and SSRF controls to the front of the design.

NHIMG editorial — based on content published by WorkOS: Client ID Metadata Documents (CIMD): How OAuth client registration works in MCP

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

Questions worth separating out

Q: How should security teams govern URL-based OAuth client identities in MCP?

A: Treat each CIMD URL as a governed non-human identity, not just a protocol field.

Q: Why do URL-based client IDs change the risk model for OAuth in MCP?

A: They move the identity anchor from a server-side registry to a client-controlled web location.

Q: What breaks when MCP clients are managed like static SaaS applications?

A: Static SaaS assumptions break because MCP clients can appear anywhere and connect to many servers with no prior relationship.

Practitioner guidance

• Inventory MCP clients as governed identities Record every URL-based client_id, its owning domain, redirect_uris, and the teams responsible for metadata updates.
• Enforce strict redirect URI allowlisting Reject any authorization request where the requested redirect_uri is not an exact match for the published redirect_uris array.
• Harden metadata fetches against SSRF Block private, loopback, link-local, reserved, and multicast IPs when resolving client_id URLs, keep fetch timeouts short, and cap document size.

What's in the full article

WorkOS's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step CIMD metadata validation logic for MCP authorization servers
• Python example code for HTTPS fetching, JSON parsing, and cache handling
• Detailed comparison of CIMD, DCR, and pre-registration in open and enterprise environments
• Implementation guidance for token endpoint auth methods and JWKS handling

👉 Read WorkOS's analysis of CIMD client registration for MCP →

CIMD for MCP auth: what changes for identity teams?

Explore further

View Full Forum →  |  NHI Foundation Course →