DCR Registration Flow

This page assumes familiarity with the MCP Auth overview. Actor terms (MCP Client, MCP Server, Authorization Server, User Agent) are defined there.

When to Use DCR

Confidential clients (server-side MCP clients that can hold a client secret)
Client cannot host a publicly reachable metadata document URL
Enterprise deployments where the Authorization Server manages the client registry
Scenarios where client_secret_post or client_secret_basic token auth is required
If your client is public and can host a metadata URL, see CIMD instead

Sequence Diagram

How It Works

Each step corresponds to an arrow in the sequence diagram above. The DCR flow is identical to the CIMD flow except for steps 7–8, which replace CIMD's step 7.

Step 1: MCP Client sends an initial MCP request to MCP Server without an access token.
Step 2: MCP Server returns HTTP 401 Unauthorized with a WWW-Authenticate header containing the resource_metadata URL.
Step 3: MCP Client requests Protected Resource Metadata from MCP Server:
```
GET https://mcp.example.com/.well-known/oauth-protected-resource
```

Step 4: MCP Server returns resource metadata including the Authorization Server issuer URI:

{
  "resource": "https://mcp.example.com/mcp",
  "authorization_servers": ["https://tenant.hub.loginradius.com/service/oidc/{app}"]
}

Step 5: MCP Client fetches Authorization Server metadata:

GET https://tenant.hub.loginradius.com/service/oidc/{app}/.well-known/oauth-authorization-server

GET https://tenant.hub.loginradius.com/.well-known/oauth-authorization-server/service/oidc/{app}

Step 6: Authorization Server returns metadata including supported endpoints and DCR capability:

{
  "issuer": "https://tenant.hub.loginradius.com/service/oidc/{app}",
  "authorization_endpoint": "https://tenant.hub.loginradius.com/service/oidc/{app}/authorize",
  "token_endpoint": "https://tenant.hub.loginradius.com/service/oidc/{app}/token",
  "registration_endpoint": "https://tenant.hub.loginradius.com/service/oidc/{app}/register",
  "client_id_metadata_document_supported": false
}

Step 7: MCP Client performs Dynamic Client Registration (DCR) by POSTing inline client metadata to the registration_endpoint.

Unlike CIMD:
- No hosted metadata URL is required
- No Authorization Server metadata fetch from the client domain occurs
- Client metadata is sent directly in the request body
Example request:
```
POST https://tenant.hub.loginradius.com/service/oidc/{app}/register
Content-Type: application/json

{
  "redirect_uris": ["https://client.example.com/callback"],
  "token_endpoint_auth_method": "client_secret_basic",
  "grant_types": ["authorization_code"],
  "response_types": ["code"]
}
```
Step 8: Authorization Server validates the registration request and returns client_id and optionally client_secret:
```
{
  "client_id": "lr_client_xyz789",
  "client_secret": "s3cr3t_aBcD1234efGH5678ijKL9012mnOP"
}
```
Supported token_endpoint_auth_method values:
- none
- client_secret_post
- client_secret_basic

Step 9: MCP Client generates PKCE parameters (code_challenge, code_verifier) using S256, includes the OAuth resource parameter, and constructs the authorization URL:

GET https://tenant.hub.loginradius.com/service/oidc/{app}/authorize
  ?response_type=code
  &client_id=lr_client_xyz789
  &redirect_uri=https://client.example.com/callback
  &scope=openid
  &code_challenge={s256_code_challenge}
  &code_challenge_method=S256
  &resource=https://mcp.example.com/mcp

Step 10: User Agent sends the authorization request to Authorization Server; user authenticates and consents. Authorization Server redirects User Agent to redirect_uri with authorization code and iss:
```
GET https://client.example.com/callback?code={authorization_code}&iss=https://tenant.hub.loginradius.com/service/oidc/{app}
```
Step 11: User Agent delivers the authorization callback to MCP Client, which verifies that iss matches the expected Authorization Server issuer (mix-up attack protection).

Step 12: MCP Client exchanges code + code_verifier + resource at the token endpoint using the client_secret_basic authentication method:

POST https://tenant.hub.loginradius.com/service/oidc/{app}/token
Authorization: Basic base64(lr_client_xyz789:s3cr3t_aBcD1234efGH5678ijKL9012mnOP)
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code={authorization_code}
&redirect_uri=https://client.example.com/callback
&code_verifier={pkce_code_verifier}
&resource=https://mcp.example.com/mcp

Step 13: Authorization Server validates the code, client authentication, and PKCE verifier, then returns tokens:

{
  "access_token": "{access_token}",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "{refresh_token}"
}

Step 14: MCP Client calls MCP tools using the access token:

POST https://mcp.example.com/mcp
Authorization: Bearer {access_token}
Content-Type: application/json

{ "method": "tools/list" }

Step 15: MCP Server validates the token and processes the MCP request.
Step 16: MCP Server returns the MCP response.

For a comparison of CIMD vs DCR fields, see the CIMD vs DCR table.