Topic starter
07/06/2026 8:29 pm
TL;DR: OAuth-based MCP discovery moved from dynamic client registration to protected resource metadata and client ID metadata documents, closing registration abuse, SSRF, and impersonation risks that made early MCP deployments hard to secure, according to WorkOS. The shift turns MCP client authentication into a cleaner identity problem, but only if teams stop treating discovery as a harmless convenience.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “How MCP Clients Find Your Auth Server (Without You Telling Them)”.
Key questions
Q: What breaks when MCP clients use dynamic registration in production?
A: Dynamic registration breaks the assumption that the authorization server only interacts with trusted clients.
Q: Why do client metadata URLs create SSRF risk in MCP onboarding?
A: Because the authorization server may fetch those URLs during client validation.
Q: How should security teams decide between DCR and CIMD for agent registration?
A: Use DCR when clients are long-lived, curated, and manageable through a persistent registry.
Practitioner guidance
- Replace open registration with metadata-based discovery Use protected resource metadata to advertise the authorization server and reserve dynamic registration only for backward compatibility or tightly controlled exceptions.
- Restrict any remaining DCR endpoints If legacy clients still require dynamic registration, isolate the endpoint, add strict allowlists, and monitor for registration floods, spoofed client names, and unusual metadata URLs.
- Validate client identity through CIMD Require client metadata to come from a URL controlled by the client and review how metadata hosting, revocation, and ownership changes are governed over time.
Bottom line: MCP client discovery became safer when it stopped depending on strangers registering themselves before trust was established.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
07/06/2026 10:24 pm
Registration-free discovery is now the right trust model for MCP. Early MCP patterns treated client onboarding as part of discovery, but that collapsed the line between locating an authorization server and admitting a new identity. Protected resource metadata and CIMD separate those functions, which is why they fit enterprise governance better than DCR does. Practitioners should treat discovery as declaration and registration as a different, much higher-risk trust decision.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What governance controls should sit around MCP client discovery?
A: Teams should inventory approved clients, define who owns client metadata, and document how revocation works when a client changes or is retired. Discovery should be paired with lifecycle governance, otherwise the protocol can make it easy to start trust relationships that no one later knows how to end.
👉 Read our full editorial: MCP client auth discovery now avoids DCR security holes
This post was modified 3 days ago by NHI Mgmt Group