Client ID Metadata Document (CIMD) Validator & Explorer

What is CIMD?

A Client ID Metadata Document (CIMD) lets an OAuth client identify itself with a URL. Instead of pre-registering with every authorization server, the client publishes a JSON document describing itself and uses that document's URL as its client_id. See the IETF draft for the full specification.

How it works

The client hosts JSON at an https URL and sends that URL as its client_id in the authorization request. The authorization server fetches the document, validates it, and checks that the client_id inside exactly matches the URL it fetched. Then it uses the declared redirect_uris and metadata for the request.

Rules the validator checks

• client_id is an https URL with a path, no dot segments, no fragment and no credentials.
• client_id exactly matches the document URL (simple string comparison).
• No shared-secret auth: client_secret_* methods and client_secret fields are rejected.
• private_key_jwt has keys, and jwks and jwks_uri are not combined.
• redirect_uris are present for redirect-based flows.
• Document size stays small (about 5 KB).

Impersonation protection

Anyone can publish a document claiming to be "Trusted App". Redirect URIs and client_uri on a different origin than the client_id are common impersonation or phishing signals, so the validator warns about them. Authorization servers should surface the client's origin to users on the consent screen.

Why it matters for MCP

MCP clients connect to many servers they have never met. CIMD gives them a way to identify themselves without dynamic client registration or manual setup at each authorization server.

CORS note

This tool fetches directly from your browser, so the server must send Access-Control-Allow-Origin. If the fetch fails, paste the JSON instead. Authorization servers fetch server-side and are not affected by CORS.