Repository navigation
Replies: 1 comment
|
In relation to MCP and client registration, there is a new proposal called the OAuth Client ID Metadata Document (CIMD) [1] as an alternative to Dynamic Client Registration (DCR), aiming to simplify registration and improve scalability. This approach addresses concerns from large IdPs (e.g., GitHub, Google) about persisting a large number of clients in Agent (MCP / A2A) scenarios. In relation to the potential solution of adding a security layer on top of the public endpoint, implementing this at the gateway level is a common best practice. [1] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00 |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Anonymous Dynamic Client Registration - Scalability & Lifecycle Management Concerns
Hello folks,
With the growing adoption of AI tooling and the MCP ecosystem, I've been exploring anonymous Dynamic Client Registration (DCR) to enable MCP clients (IDEs, coding assistants, etc.) to autonomously create Keycloak clients. This would allow their users to obtain JWTs via the Authorization Code flow and access MCP Servers that require authorization.
I've encountered two challenges:
1. Unbounded Client Creation
It is possible to create an unlimited number of clients through anonymous DCR. The default realm threshold of 300 clients could be easily exhausted through a DDoS attack, potentially impacting legitimate users.
2. Missing Client Creation Timestamp
There doesn't seem to be a built-in timestamp indicating when a client was created. While there is a
CLIENT_REGISTRATIONuser event, it gets purged over time (similar toLOGINevents). This makes it difficult to crossreferenceCLIENT_REGISTRATIONwithLOGINevents and implement proper lifecycle management—e.g. distinguishing between a client registered 5 minutes ago that hasn't been used yet versus one that has been stale for a year.Potential Solutions
I've been considering a few approaches and would appreciate any feedback:
created_attimestamp per client to support cleanup jobs and retention policiesQuestions for the Community
Thanks in advance! I'm happy to contribute if there's interest in tackling these issues.
All reactions