For MCP, use pre-registered client credentials when you have a relationship with the server, Client ID Metadata Documents when you do not, and dynamic client registration as a fallback. The specification lists that order. The newer metadata document approach uses an HTTPS URL as the client ID, which the authorization server fetches and validates.
Definitions
Client registration. How an OAuth authorization server learns about a client: its ID, name and allowed redirect URIs.
Pre-registration. A person or admin registers the client in advance, and the client holds a fixed ID.
Dynamic client registration (RFC 7591). The client calls a registration endpoint and receives an ID automatically. The specification keeps it mainly for backwards compatibility.
Client ID Metadata Document. The client ID is an HTTPS URL with a path, for example a JSON file the client hosts. It must contain at least client_id, client_name and redirect_uris, and client_id must match the URL exactly.
Comparison
| Approach | Fits when | Main risk to manage |
|---|---|---|
| Pre-registration | Client and server already have a relationship | Credential handling and rotation |
| Client ID Metadata Document | No prior relationship, the common MCP case | The authorization server fetches an arbitrary URL, so SSRF controls matter |
| Dynamic client registration | Backwards compatibility | Open registration invites impersonation and, with proxies, confused deputy flaws |
How a metadata document flow runs
- The client sends an authorization request with its HTTPS URL as client_id.
- The authorization server sees a URL, fetches the document and checks that client_id matches the URL, that the document is valid JSON with required fields, and that the redirect URI in the request appears in the document.
- It shows a consent page with the client name and approves or rejects.
- It can cache the document according to HTTP cache headers.
Authorization servers advertise support with client_id_metadata_document_supported set to true in their metadata.
Cautions from the specification
- SSRF. The server takes a URL from an unknown client and fetches it. Block private addresses and think through redirects.
- Localhost impersonation. A metadata document cannot stop an attacker using a legitimate client's URL with their own localhost redirect. Servers should warn on localhost-only redirect URIs and display the redirect hostname.
- Trust policy. Servers may allowlist domains, accept any HTTPS client ID, or check reputation. Show the hostname prominently to resist phishing.
Choosing for your server
- Internal tool with a known client list: pre-register.
- Public server meant to work with many clients: support metadata documents and add trust policy.
- Existing deployments with older clients: keep dynamic registration, but require per-client consent if you proxy to a third party.
Quick check
Is dynamic client registration deprecated?
The specification says it may be supported and describes it as included for backwards compatibility. It is not removed.
Why must client_id match the document URL?
It stops a document at one URL from claiming to be a different client. The authorization server must validate the match.
Do metadata documents remove the need for consent screens?
No. The server still shows a consent page naming the client, and should show the redirect hostname.
Where Safeguard fits
Safeguard offers asset discovery and agent identity so you can see which agents and MCP clients exist in your environment. Start with a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
