Notifications
Clear all
Topic starter
07/06/2026 8:39 pm
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
08/06/2026 8:17 am
CIMD exposes a governance gap in how organisations think about client identity. The old model assumes a non-human client is introduced once, stored centrally, and managed like a durable registry entry. CIMD breaks that assumption by making the URL itself the identity, which is more scalable for MCP but also less familiar to IAM programmes built around static onboarding. The implication is that client identity governance now has to follow the web-native object, not the database row.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- 53% of MCP servers expose credentials through hard-coded values in configuration files, which shows how quickly MCP governance fails when identity and secret handling are left informal.
A question worth separating out:
Q: Who is accountable when a CIMD client is impersonated or misconfigured?
A: Accountability is shared across the client owner, the authorization server operator, and the platform team that approved the scope. The client owner must keep metadata accurate, the server must validate it correctly, and the platform team must decide whether the identity is trusted enough for the requested access.
👉 Read our full editorial: Client ID metadata documents change OAuth client registration in MCP
