What
Third (final) phase of docs/plans/oauth-authorization-server.md. Phases 1+2 (DCR + authorize/token + gateway JWTs, rotating refresh tokens, admin client management) shipped in v0.4.0/v0.5.0 and are verified in prod.
CIMD (Client ID Metadata Documents) — the client registration mechanism the MCP spec (revision 2025-11-25) recommends: instead of registering via RFC 7591 DCR and receiving a server-issued client_id, the client identifies itself with an HTTPS URL pointing to a JSON metadata document (redirect_uris, client_name, …). The AS fetches and validates that document itself.
Fixes DCR's structural downsides, already visible in our admin UI after one day in prod:
- client rows accumulate forever (every
claude mcp add / device = a new row)
- client identity is self-asserted (
client_name: "Claude Code" proves nothing; a client_id under https://claude.ai/… does)
- the anonymous register endpoint needs rate-limiting; CIMD has no registration step at all
Scope (additive on top of DCR — DCR stays as fallback)
/oauth/authorize: when client_id is an https:// URL → fetch the metadata document (cached), validate redirect_uri against the document's redirect_uris, skip the oauth_clients table entirely./oauth/token: codes and refresh tokens already bind to the client_id string — the URL just flows through; no schema migration expected.- AS metadata: advertise
client_id_metadata_document_supported: true.
- SSRF guards on the fetch (the URL arrives from an anonymous party): https only, block private/link-local/loopback IPs (incl. DNS-rebinding re-check), response size limit, timeout, content-type check, positive+negative cache.
- Tests mirroring the DCR suite: happy path, redirect_uri mismatch vs the doc, SSRF-guard rejections, cache behavior.
When
Deliberately deferred: stock Claude clients connect fine via DCR today. Trigger for picking this up — authorize errors in the logs with URL-shaped client_id values (clients starting to send CIMD identifiers).
Refs: MCP auth spec 2025-11-25 (SEP-991), draft-ietf-oauth-client-id-metadata-document.
🤖 Generated with Claude Code
What
Third (final) phase of
docs/plans/oauth-authorization-server.md. Phases 1+2 (DCR + authorize/token + gateway JWTs, rotating refresh tokens, admin client management) shipped in v0.4.0/v0.5.0 and are verified in prod.CIMD (Client ID Metadata Documents) — the client registration mechanism the MCP spec (revision 2025-11-25) recommends: instead of registering via RFC 7591 DCR and receiving a server-issued
client_id, the client identifies itself with an HTTPS URL pointing to a JSON metadata document (redirect_uris,client_name, …). The AS fetches and validates that document itself.Fixes DCR's structural downsides, already visible in our admin UI after one day in prod:
claude mcp add/ device = a new row)client_name: "Claude Code"proves nothing; aclient_idunderhttps://claude.ai/…does)Scope (additive on top of DCR — DCR stays as fallback)
/oauth/authorize: whenclient_idis anhttps://URL → fetch the metadata document (cached), validateredirect_uriagainst the document'sredirect_uris, skip theoauth_clientstable entirely./oauth/token: codes and refresh tokens already bind to theclient_idstring — the URL just flows through; no schema migration expected.client_id_metadata_document_supported: true.When
Deliberately deferred: stock Claude clients connect fine via DCR today. Trigger for picking this up — authorize errors in the logs with URL-shaped
client_idvalues (clients starting to send CIMD identifiers).Refs: MCP auth spec 2025-11-25 (SEP-991), draft-ietf-oauth-client-id-metadata-document.
🤖 Generated with Claude Code