Notifications
Clear all
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.
NHIMG editorial — based on content published by WorkOS: How MCP Clients Find Your Auth Server (Without You Telling Them)
By the numbers:
- The June 2025 spec revision introduced Protected Resource Metadata (RFC 9728).
- The November 2025 spec revision introduced Client ID Metadata Document (CIMD), which flips the trust model entirely.
Questions worth separating out
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 MCP discovery flows change the identity governance model?
A: MCP discovery changes governance because the server must declare where clients authenticate instead of relying on ad hoc configuration.
Q: How do security teams know whether MCP client onboarding is too permissive?
A: Onboarding is too permissive when unknown clients can register, supply arbitrary metadata URLs, or obtain credentials before a meaningful trust check.
Practitioner guidance
- Remove public registration from production MCP paths Disable dynamic client registration wherever CIMD or protected resource metadata can satisfy the client discovery flow.
- Constrain metadata fetching to approved destinations If any discovery or validation flow fetches client-controlled URLs, restrict outbound requests, block metadata IP ranges, and log every fetch.
- Make authorization-server discovery explicit in the resource server Publish a well-known resource metadata endpoint and return a WWW-Authenticate challenge that points clients to the correct authorization server.
What's in the full article
WorkOS's full research covers the operational detail this post intentionally leaves for the source:
- The exact OAuth discovery flow and header behavior used by MCP servers in production.
- Code examples for the well-known resource metadata endpoint and JWKS validation setup.
- The transition path from DCR to CIMD for teams that must support older clients.
- Implementation guidance for enabling CIMD in the WorkOS Dashboard.
👉 Read WorkOS's analysis of MCP auth discovery and client registration risks →
MCP auth discovery and client registration risks in practice?
Explore further
07/06/2026 10:24 pm
Dynamic client registration was built for onboarding, not for hostile internet exposure. The moment an MCP server lets unknown clients register themselves, it accepts an identity claim before it has any durable basis for trust. That assumption fails because attacker-controlled metadata turns registration into an attack surface, not a governance control. Practitioners should treat open registration as a broken premise in production MCP.
A few things that frame the scale:
- Most enterprise identity providers, including Okta, Azure AD, and Ping, disable DCR by default, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- The same research found that when AWS credentials are exposed publicly, attackers attempt access within 17 minutes on average, showing how quickly identity exposure turns into action.
A question worth separating out:
Q: Should organisations keep dynamic client registration enabled for older MCP clients?
A: Only as a tightly controlled exception. If older clients require DCR, isolate them, log all registrations, and limit where they can operate. New deployments should move to protected resource metadata or CIMD so the default architecture no longer depends on a public registration endpoint.
👉 Read our full editorial: MCP client auth discovery now avoids DCR security holes
