Why MCP builders are transitioning from DCR to OAuth Client ID Metadata
Over the last year, MCP has surged in adoption. To little surprise, this has introduced some scaling issues. One of these is client registration; previously, systems were rigged together by humans. Today, AI agents discover and interface with MCP servers freely, requiring a new paradigm for client communications.
Originally, the only solution was Dynamic Client Registration (DCR). DCR outlined the mechanics for clients to automatically register with MCP servers without human involvement at runtime. However, DCR created new problems; it places all of the burden on the authorization server and also is particularly vulnerable for client impersonation attacks.
To address these, an old OAuth protocol known as Client ID Metadata Document (CIMD) provides an alternative approach. CIMD inverts the model, where clients are tasked to host their own metadata. We’re quite excited about this direction of the market—let’s dive in.
The Issue with Dynamic Client Registration
MCP servers are bountiful. There are MCP servers for each integrations, for each microservice, for each company department. There are just as many clients that take shape of AI agents or LLM chat applications. Dynamic Client Registration, which originally emerged as a technique for mobile applications to independently authorize with devices, was a solution that instructed clients on how to attain client IDs with servers autonomously.
However, DCR created new challenges. First, DCR is an open system. Anyone could register, and while authorization servers could implement their own logic to tackle threat actors, DCR alone doesn’t protect them.
Now, servers must create their own registration policies for authorizing agents. Additionally, every registration endpoint is now an attack service.
These constraints paved the way for CIMD.
What is a Client ID Metadata Document?
CIMD shifts the burden from authorization servers onto MCP clients.
Previously, authorization servers had to store client information for all dynamically registered clients. Additionally, authorization servers had to build mechanisms to verify that the client service was legitimate and not impersonating an otherwise trustworthy identity. With CIMD, both of these issues are solved by relegating client metadata to the client.
CIMD is specifically a document that each client publicly hosts. When the client makes a request to the authorization server, the authorization server fetches the client’s metadata document. Authorization server then validates that metadata; after, it can proceed with standard OAuth.
By using a public URL, CIMD effectively frees the authorization server from having to store excessive client metadata. Additionally, CIMD simplifies client identification by using the client metadata URL as its identifier. Therefore, to prevent impersonation, the authorization server could easily compare the client’s known identifier with the CIMD to ensure that they’re coming from the same origin. Additionally, if the CIMD is missing, then the request fails, effectively eliminating the counterpart DCR hazard of a stale entry being used for impersonation.
Notably, CIMD predates modern AI, with origins in IndieAuth, an authorization framework built on OAuth 2.0. Today, it’s on the precipice of being integrated into the MCP spec.
Does CIMD introduce latency?
One concern with CIMD is that authorization servers have to fetch the client’s metadata on a per request basis. Accordingly, this could introduce a lot of latency, especially for applications that involve a burst of sequential requests.
However, CIMD only specifies the mechanics for access metadata. It remains up to authorization servers if they want to cache metadata and for how long; for applications with the right tolerance, a lengthier cache is appropriate.
Who is using CIMD?
While CIMD isn’t officially merged into the MCP specification yet, some companies, such as Bluesky, use CIMD in production. For Bluesky’s OAuth API, clients must use CIMD to accommodate Bluesky’s decentralized model.
What are security concerns of CIMD?
One outstanding security concern of CIMD is that authorization servers now need to fetch information from untrustworthy URLs. This could potentially overwhelm the authorization server if responses are unconventionally massive. Alternatively, it could slow down the authorization server if requests are incredibly slow.
To avoid these, authorization servers should enforce limits on payload sizes, have aggressive timeouts, and maintain a list of metadata URLs to block in the case of abuse.
Closing Thoughts
If you are interested in building scalable AI systems with MCP, consider booking a demo with Runlayer. Runlayer is an enterprise-ready governance and orchestration platform that connects MCP servers and clients via a shared registry. Runlayer has built-in telemetry, security, access controls, and other enterprise critical features.
Discover enterprise-ready governance and the future of MCP today.
