Implement Client ID Metadata Documents (CIMD) for MCP Authorization (SEP-991)

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem

GitLab's MCP server currently supportes Dynamic Client Registration (DCR) which allows just-in-time registration by sending client metadata to a register endpoint on the Authorization server. The current DCR registrations causes problems with MCP Oauth for two points:

  • DCR requires servers to manage unbounded databases, handle expiration, and trust self-asserted metadata

A user might connect to multiple different MCP clients that each reach require registering a new Dynamic Registered Oauth application. Each instance needs its own redirect URI. GitLab's authorization server would accumulate permanent records for every client instance which is unsustainable assuming there are over 1M instances of newly dynamic registered application.

Solution

Instead of GitLab storing client registrations, Client ID Metadata Documents (CIMD) mandates the client host their own metadata at an HTTPS URL. That URL becomes the client ID.

When a client starts OAuth, GitLab fetches the metadata from the URL, validates it matches the client's identity, and proceeds. No persistent storage needed. The metadata can be cached temporarily, but there's no registration database to maintain.

All instances of Claude Desktop share one metadata URL. All VS Code users point to the same document. The M×N registration problem becomes a simple fetch operation.

References

Epic: &20387

Edited by Nathan Weinshenker