Client Registration

• Client ID Metadata Documents: When client and server have no prior relationship (most common)
• Pre-registration: When client and server have an existing relationship
• Dynamic Client Registration: For backwards compatibility or specific requirements

1. Use pre-registered client information for the server if the client has it available
2. Use Client ID Metadata Documents if the Authorization Server indicates if the server supports it (via client_id_metadata_document_supported in OAuth Authorization Server Metadata)
3. Use Dynamic Client Registration as a fallback if the Authorization Server supports it (via registration_endpoint in OAuth Authorization Server Metadata)
4. Prompt the user to enter the client information if no other option is available

​

Client ID Metadata Documents

​

Implementation Requirements

• Clients MUST host their metadata document at an HTTPS URL following RFC requirements
• The client_id URL MUST use the “https” scheme and contain a path component, e.g. https://example.com/client.json
• The metadata document MUST include at least the following properties: client_id, client_name, redirect_uris
• Clients MUST ensure the client_id value in the metadata matches the document URL exactly
• Clients MAY use private_key_jwt for client authentication (e.g., for requests to the token endpoint) with appropriate JWKS configuration as described in Section 6.2 of Client ID Metadata Document

• SHOULD fetch metadata documents when encountering URL-formatted client_ids
• MUST validate that the fetched document’s client_id matches the URL exactly
• SHOULD cache metadata respecting HTTP cache headers
• MUST validate redirect URIs presented in an authorization request against those in the metadata document
• MUST validate the document structure is valid JSON and contains required fields
• SHOULD follow the security considerations in Section 6 of Client ID Metadata Document

​

Example Metadata Document

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "client_uri": "https://app.example.com",
  "logo_uri": "https://app.example.com/logo.png",
  "redirect_uris": [
    "http://127.0.0.1:3000/callback",
    "http://localhost:3000/callback"
  ],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

​

Client ID Metadata Documents Flow

​

Discovery

{
  "client_id_metadata_document_supported": true
}

​

Preregistration

1. Hardcode a client ID (and, if applicable, client credentials) specifically for the MCP client to use when interacting with that authorization server, or
2. Present a UI to users that allows them to enter these details, after registering an OAuth client themselves (e.g., through a configuration interface hosted by the server).

​

Dynamic Client Registration

​

Application Type and Redirect URI Constraints

• Native applications (desktop applications, mobile apps, CLI tools, and locally-hosted web applications accessed via localhost) SHOULD use application_type: "native"
• Web applications (remote browser-based applications served from a non-local host) SHOULD use application_type: "web"

​

Authorization Server Binding