Implement server-side support for Client ID Metadata Documents (CIMD)

Summary

PR #1652 implemented client-side support for Client ID Metadata Documents (CIMD) per SEP-991, but the server-side implementation is missing. Authorization servers built with the Python SDK cannot currently support CIMD.

Background

CIMD (draft-ietf-oauth-client-id-metadata-document-00) allows OAuth clients to use HTTPS URLs as client identifiers, where the URL points to a JSON document containing client metadata. This is the recommended registration approach per the MCP spec (ahead of DCR).

From the MCP Authorization spec:

Authorization servers and MCP clients SHOULD support OAuth Client ID Metadata Documents

Current State

Client-side (implemented in #1652)

• ✅ is_valid_client_metadata_url() - validates HTTPS URLs with path component
• ✅ should_use_client_metadata_url() - checks if server advertises CIMD support
• ✅ create_client_info_from_metadata_url() - uses URL as client_id
• ✅ OAuth flow integration with DCR fallback

Server-side (missing)

• ❌ Never advertises client_id_metadata_document_supported=true in OAuth metadata
• ❌ No detection of URL-formatted client_ids
• ❌ No metadata document fetching
• ❌ No validation (client_id matching, redirect_uri verification, document structure)
• ❌ No caching infrastructure
• ❌ No SSRF protection for fetching

Spec Requirements for Authorization Servers

From the MCP spec and CIMD RFC:

References

• MCP Spec: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#client-id-metadata-documents
• CIMD RFC: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00
• SEP-991: https://github.com/modelcontextprotocol/modelcontextprotocol/issues/991
• Client-side PR: #1652
• Original tracking issue: #1538 (closed prematurely - only client-side was implemented)

_{AI Disclaimer}

Commencez par examiner la prise en charge de CIMD côté client dans PR #1652, ainsi que les métadonnées OAuth du SDK et la gestion de l’autorisation côté serveur. Faites correspondre la détection de l’URL client_id manquante, la récupération des documents, la validation, la mise en cache et les protections SSRF aux points d’entrée existants. Le travail est considéré comme terminé lorsque les serveurs d’autorisation annoncent la prise en charge de CIMD et satisfont aux exigences CIMD et MCP indiquées, sans mettre en cache les erreurs.