Client ID metadata documents change OAuth client registration in MCP

At a glance

What this is: Client ID Metadata Documents turn OAuth client registration into URL-based, stateless identity for MCP clients, with strict metadata validation and caching rules.

Why it matters: IAM and platform teams need to understand this pattern because it changes how non-human identities are introduced, validated, and governed across open MCP ecosystems, not just how they authenticate.

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.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 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.

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

Context

Client ID Metadata Documents, or CIMD, replace the old assumption that every OAuth client must be pre-registered in a central database. In open MCP environments, that assumption breaks because clients may connect to thousands of servers they have never seen before, so identity has to be discoverable, stable, and verifiable through the web itself.

For identity teams, the issue is not only registration mechanics. CIMD changes where trust lives: the client’s HTTPS domain becomes the identity anchor, while the authorization server must validate redirect URIs, metadata integrity, and caching behaviour before it grants access. That makes MCP governance a non-human identity problem with protocol-level implications.

The practical question is whether your current IAM and NHI controls still assume static onboarding, fixed registries, and centrally minted client records. If they do, CIMD exposes a gap between how modern MCP clients behave and how legacy authorization workflows still think identities should behave.

Key questions

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. Track ownership, allowed redirect URIs, metadata change history, and revocation paths, then apply policy before scopes are granted. A valid client_id proves domain control, but it does not prove the client should receive sensitive access.

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. That improves scale and portability, but it also means authorization now depends on metadata validation, redirect URI matching, and SSRF-safe fetching. The security boundary shifts from registration workflow to runtime verification.

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. If teams expect fixed onboarding, permanent records, and one-time registration, they miss URL ownership drift, cached metadata staleness, and the need for policy above identity.

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.

Technical breakdown

How CIMD replaces dynamic client registration in MCP

CIMD inverts the classic OAuth registration model. Instead of an authorization server storing client records up front, the client publishes a JSON metadata document at a stable HTTPS URL and uses that URL as the client_id. The server fetches the document on demand, validates its contents, and can cache it with normal HTTP controls such as ETag and Cache-Control. In MCP, that makes client identity portable across servers without creating a writable registration endpoint for every new client.

Practical implication: treat the client’s hosted metadata URL as an identity object that needs validation, monitoring, and lifecycle control.

OAuth client_id metadata and redirect URI validation

CIMD still relies on the same OAuth safety properties that stop impersonation. The server must confirm that the document’s client_id exactly matches the URL presented in the request, that the document is valid JSON over HTTPS, and that the requested redirect_uri is one of the allowed redirect_uris. That redirect check is the core anti-phishing control because it prevents a client from claiming one identity while sending the authorization response to another destination.

Practical implication: enforce exact-match redirect URI allowlisting and reject any client metadata that does not line up byte-for-byte with the requested identity.

SSRF risk and cache design for stateless client identity

Because the server fetches a URL supplied by the client, CIMD introduces an SSRF exposure if implementations do not constrain DNS resolution and private-IP targets. The article’s example shows why servers should block loopback, link-local, reserved, and multicast addresses, keep fetch timeouts short, and bound document size. Caching is also part of the security model: without TTL, eviction, and conditional requests, a high-volume MCP server can turn client metadata lookups into a resource exhaustion problem.

Practical implication: pair client metadata fetches with SSRF filtering, bounded response handling, and strict cache eviction rules.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Client registration without lifecycle offboarding is becoming a structural weakness in MCP estates. If the identity lives at a URL, then control is no longer just about granting access at registration time. It also depends on whether the URL, metadata, redirect set, and any key material remain aligned with the client’s real operational state. That makes offboarding, ownership change, and metadata drift first-class governance issues for non-human identities.

Identity blast radius increases when the same client identity can appear across many MCP servers. CIMD is designed for interoperability, but that also means one client identity may be trusted in multiple places unless policy is layered on top. The field should stop treating registration as the security boundary and start treating downstream authorisation scope as the real boundary. Practitioners should assume that portability without policy creates a wider blast radius than many current IAM reviews account for.

Stateless client identity is a named concept that improves scale but shifts security work into validation and policy. CIMD removes write-side registration pressure, but it does not answer whether a client should receive access, only whether it controls the claimed URL. That distinction matters because many enterprise IAM patterns still conflate identity proof with trust approval. Practitioners need to separate who the client is from what it should be allowed to do.

MCP governance is now a non-human identity discipline, not just an OAuth implementation detail. The control questions are the same ones identity teams already ask for service accounts and workload identities: who owns it, how is it validated, what breaks when the metadata changes, and how is access withdrawn. The organisations that fold CIMD into NHI governance early will be better positioned than those that treat it as a narrow protocol feature.

From our research:

• 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.
• The Ultimate Guide to NHIs shows how lifecycle governance, not just registration mechanics, becomes the deciding control as machine identities proliferate.

What this signals

CIMD will force IAM teams to think about client identity as a living web object. That matters because the operational questions are no longer limited to provisioning. They now include ownership drift, metadata freshness, redirect set changes, and whether downstream access remains appropriate after the identity’s publishing context changes.

A useful way to think about this is identity blast radius. When one URL-based client_id can be accepted by many MCP servers, the trust problem multiplies unless policy, scoping, and revocation are tied to the same governance layer. Teams that already understand workload identity and service-account governance will adapt faster than teams still separating auth from lifecycle.

With 33% of organisations already reporting AI agents accessing inappropriate or sensitive data beyond their intended scope, per AI Agents: The New Attack Surface report, the market signal is clear: protocol elegance is not the same as governance maturity. MCP adopters should expect pressure to add policy, auditability, and identity ownership controls around client registration flows.

For practitioners

• Inventory MCP clients as governed identities Record every URL-based client_id, its owning domain, redirect_uris, and the teams responsible for metadata updates. Treat the CIMD document as an identity record that needs ownership, review, and offboarding, not just a technical endpoint.
• 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. This control is the primary defence against client impersonation and token leakage in CIMD-based flows.
• 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. The client-controlled URL is part of the attack surface, so outbound validation has to be treated as security logic.
• Bind cache behaviour to identity freshness Use HTTP caching headers, bounded TTLs, and eviction rules so stale client metadata does not linger indefinitely. Revalidate cached CIMD documents whenever the redirect set, key material, or ownership posture changes.
• Separate proof of control from trust approval Require an explicit policy layer above CIMD before granting sensitive scopes, especially in open or multi-tenant MCP environments. A valid HTTPS URL proves domain control, not suitability for access to tools, resources, or data.

Key takeaways

• CIMD changes MCP client registration from a writable database problem into a web-native identity problem that still needs strict validation.
• The main risks are not just scalability and interoperability, but SSRF exposure, redirect spoofing, and identity drift across many servers.
• Practitioners should govern URL-based client IDs like other non-human identities, with ownership, policy, revocation, and cache freshness all in scope.

Key terms

• Client ID Metadata Document: A Client ID Metadata Document is a JSON file hosted at a stable HTTPS URL that serves as the OAuth client identifier. In MCP, the URL itself becomes the client_id, while the authorization server fetches and validates the metadata before deciding whether to continue the flow.
• Stateless Client Registration: Stateless client registration is a model where the authorization server does not store a permanent record for every client at onboarding time. Instead, it retrieves client metadata on demand, validates it, and may cache it temporarily, which improves scale but increases the importance of runtime checks.
• Redirect URI Allowlisting: Redirect URI allowlisting is the practice of permitting only predeclared callback URLs during OAuth authorization. For CIMD, it is the main anti-impersonation control because the client must prove that the requested redirect destination matches the published metadata exactly.
• Identity Blast Radius: Identity blast radius is the amount of downstream access that can be affected when a single identity is trusted across multiple systems. For MCP and CIMD, the blast radius grows when one URL-based client_id is accepted by many servers without separate policy layers or access scoping.

Deepen your knowledge

CIMD, OAuth client registration, and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are adapting IAM controls for MCP clients, it is worth exploring.

This post draws on content published by WorkOS: Client ID Metadata Documents (CIMD): How OAuth client registration works in MCP. Read the original.