MCP Server β€” Dynamic Client Registration (DCR) Flow

Introduction

This diagram shows the successful authorization flow for a MCP Host with Dynamic Client Registration (DCR) capability using the Authorization Code Grant defined in OAuth 2.0.

OAuth 2.0 Dynamic Client Registration supports both confidential and public clients. In deployments where dynamically registered clients cannot securely maintain long-term client credentials, the DCR Proxy can act as a trusted intermediary for secure token handling.

Flow Summary

Grant TypeAuthorization Code
User AuthenticationRequired
Browser RedirectsYes
Refresh TokensOptional

Typical Use Cases

  • Desktop AI Assistants
  • MCP Hosts without pre-provisioned OAuth Clients
  • Third-party MCP Hosts connecting to protected MCP Servers

You can find the Quick Start guide for MCP Server β€” DCR in the Mekarge A3 documentation. Please note that the implementation in the Quick Start guide embeds DCR Proxy functionality into the MCP Server.

Flow

Explanations

  1. The MCP Host discovers the MCP Server’s authorization requirements.
  2. πŸ’‘ Hints

    In practice, the flow typically begins when the MCP Host attempts to access a protected MCP resource and receives an authorization challenge from the MCP Server

    πŸ’‘ Hints

    MCP Server can expose OAuth protected resource metadata so clients can discover the related authorization server information. Read more about OAuth 2.0 Protected Resource Metadata in RFC 9728

  3. The MCP Server returns the DCR Proxy as the authorization server in protected resource metadata.
  4. πŸ’‘ Hints

    In the Quick Start guide for " MCP Server β€” DCR", the authorization server points to the MCP Server itself, as both DCR Proxy and MCP Server functionalities are merged into a single server.

  5. The MCP Host fetches authorization server metadata from DCR Proxy.
  6. πŸ’‘ Hints

    MCP Authorization specification references both RFC 8414 discovery and OpenID Connect Discovery in the metadata discovery section. Read more about accessing discovery endpoints and order of preference in MCP Authorization Specification β€” Authorization Server Metadata Discovery.

    Read more about OpenID Connect Discovery in OpenID Connect Discovery 1.0

    Read more about OAuth 2.0 Authorization Server Metadata in RFC 8414

  7. DCR Proxy returns authorization server metadata including dynamic client registration endpoint.
  8. The MCP Host dynamically registers with the DCR Proxy.
  9. πŸ’‘ Hints

    Read more about Dynamic Client Registration in RFC 7591

  10. The DCR Proxy returns client credentials to the MCP Host. Internally, the DCR Proxy can still use fixed Client credentials when communicating with Mekarge A3.
  11. The MCP Host opens the user's browser.
  12. The MCP Host starts a browser-based authorization flow by sending the user to the DCR Proxy's Authorization Endpoint.
  13. The DCR Proxy responds with HTTP 302.
  14. πŸ’‘ Hints

    In the Quick Start guide for "MCP Server β€” DCR", the DCR Proxy (MCP Server itself) displays a consent screen informing the user about the dynamically registered Client and the requested access before redirecting to Mekarge A3.

  15. The browser is redirected to the Authorization Endpoint in Mekarge A3.
  16. Mekarge A3 returns an authentication page containing a login form.
  17. The browser submits the authentication form to Mekarge A3.
  18. Mekarge A3 validates the User credentials and responds with HTTP 302.
  19. The browser is redirected to the Redirect URI in DCR Proxy with the Authorization Code generated by Mekarge A3.
  20. The DCR Proxy calls the Token Endpoint in Mekarge A3 with the Authorization Code.
  21. Mekarge A3 validates the Authorization Code and returns an Access Token.
  22. The DCR Proxy generates a "Proxy" Authorization Code for the MCP Host and responds with HTTP 302.
  23. πŸ’‘ Hints

    The "Proxy" Authorization Code is generated by the DCR Proxy and is independent from the Authorization Code issued by Mekarge A3. It allows the DCR Proxy to exchange the original Access Token for a delegated Access Token managed within the proxy layer.

  24. The browser opens MCP Host application.
  25. The MCP Host calls the Token Endpoint in DCR Proxy with the "Proxy" Authorization Code.
  26. The DCR Proxy returns a delegated Access Token to the MCP Host. Internally, the DCR Proxy associates delegated Access Token with the one received from Mekarge A3.
  27. πŸ’‘ Hints

    The delegated Access Token can be either an opaque token or in JWT format. In the former case, the Access Token claims should be accessible through an Introspection Endpoint. All introspection calls to that Introspection Endpoint must be relayed to Mekarge A3 with the associated Access Token.

    DCR Proxy is encouraged to provide an Introspection Endpoint in all cases.

    Read more about OAuth 2.0 Token Introspection in RFC 7662

    The delegated Access Token must:

    • Keep scope and Mekarge-specific context claims from the Access Token issued by Mekarge A3.

    The delegated Access Token should:

    • Keep claims iat, exp and nbf claims from the Access Token issued by Mekarge A3.

  28. The MCP Host calls the MCP Server using the delegated Access Token.
  29. The MCP Server validates the delegated Access Token and returns the result.
  30. πŸ’‘ Hints

    MCP Server may delegate validation to the DCR Proxy as well.

    πŸ’‘ Hints

    In the Quick Start guide for " MCP Server β€” DCR", validation is handled internally, as both DCR Proxy and MCP Server functionalities are merged into a single server.

Notes

Security

  • Protect Dynamic Client Registration endpoints against unauthorized or excessive registrations.
  • Allow only pre-approved or policy-validated Redirect URIs during Dynamic Client Registration.
  • Mekarge A3 allows only HTTPS for Redirect URIs.
  • Use HTTPS for all API endpoints.
  • Store Access Tokens and Refresh Tokens securely on the DCR Proxy.
  • Enable PKCE to follow OAuth 2.1 security best practices. (See OAuth 2.1 Β§7.8).
  • Configure short-lived Access Tokens.
  • Delegated Access Tokens should not outlive the original Access Token issued by Mekarge A3.
  • Avoid storing original Access Tokens longer than required for delegation and introspection.