docs(mcp): document CIMD, opt-in DCR, and the consent screen - #86
Merged
Conversation
Adds the CIMD section: the document shape, that client_id must equal its own URL, the SSRF-hardened fetch, and the consent screen that comes with it — plus why consent applies to self-registered clients and not to ones an operator registered. Corrects the Claude Code row: the OAuth path works with --enable-client-id-metadata-document, where before it was refused outright. The row says plainly that the browser leg has not been verified end to end here, because the previous version of this table overstated exactly that.
✅ Deploy Preview for authorizerdev-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
The docs said Authorizer "deliberately does not implement RFC 7591" and that self-registering clients could not connect. Both shipped in 2.4.0: CIMD as the preferred mechanism, DCR behind --enable-dynamic-client-registration for clients that predate it. The vendor arguments collected against DCR still stand as reasons to keep it OFF by default, and they are kept rather than deleted - with the mitigations answering each one. What changed is the premise: the reasoning was about what should be preferred, not about what shipping clients can do. Claude Code reads client_id_metadata_document_supported and still refuses without a registration_endpoint. Updates the compatibility matrix (self-registering clients now "yes", Claude Code OAuth now verified through registration), replaces "Why there is no /register endpoint" with "Self-registering clients: CIMD vs DCR", and corrects the OIDC, SSO and spec pages that listed DCR as unimplemented.
lakhansamani
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Companion to authorizerdev/authorizer#758.
Documents both self-registration mechanisms — Client ID Metadata Documents (preferred) and RFC 7591 dynamic client registration (opt-in, for clients that predate CIMD) — and the consent screen that necessarily comes with both.
The correction this makes
These pages said Authorizer "deliberately does not implement RFC 7591" and "this is unlikely to change". That reasoning was about what should be preferred, and it still holds — but it was wrong about what shipping clients can do. Claude Code reads
client_id_metadata_document_supported: truefrom our metadata, ignores it, and still refuses without aregistration_endpoint. CIMD alone left the flagship client unable to connect.The vendor arguments against DCR (Auth0, Keycloak, Anthropic) are kept, not deleted — they are the reason it ships off by default — and each now sits beside the mitigation that answers it:
client_credentialsrefused;redirect_urishttps or loopback http/authorize; implicit refusedPages changed
docs/core/mcp.md— compatibility matrix (self-registering clients now yes; Claude Code OAuth row now records the verifiedPOST /oauth/register→ 201), and "Why there is no/registerendpoint" → "Self-registering clients: CIMD vs DCR" with copy-pasteable flags and a registration exampledocs/core/oauth2-oidc.md— DCR removed from "not yet implemented"; discovery check now saysregistration_endpointis absent unless the flag is setdocs/core/sso-guide.md— DCR no longer "on the roadmap"; scoped to public MCP-style clients, with confidential clients still admin-registeredspecs/2026-08-10-mcp-http-transport.md— "Not planned" marked superseded, with whyspecs/2026-08-11-cimd-and-consent.md— DCR moved out of "Out of scope"Verification status, stated honestly
Registration is verified: Claude Code 2.1.226 walks discovery and registers (
POST /oauth/register→ 201, public client, loopback callback). The interactive browser leg is a TUI that cannot be driven headlessly, so it is handed to a human rather than claimed here — the same discipline the previous version of this table got wrong once already.