Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.alpic.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
What is Alpic’s DCR proxy?

MCP only support OAuth as an official authentication mechanism to protect servers. While most features required to make MCP work lives within OAuth 2.O, the protocol require a specific feature of OAuth 2.1: Dynamic Client Registration (DCR). Many identity providers (Auth0, Google, etc.) don’t natively support DCR. Alpic bridges this gap with a DCR proxy: Alpic exposes a set of OAuth endpoints on top of your provider. When an MCP client connects to your server, it goes through Alpic endpoints which in turn use the OAuth metadata from your server. Alpic issues client credentials as part of the DCR spec. Only a single set of client credentials are in effective use from your auth provider perspective. We handle the complexity of keeping track of all OAuth client issued to use your MCP server. All those clients are stored in Alpic in a client pool.

​
How it works

  1. You create a client pool in your environment’s authentication settings, providing the client ID, secret, and scopes of a single OAuth client you created on your identity provider.
  2. Alpic advertises a registration_endpoint in your server’s OAuth discovery metadata.
  3. When an MCP client connects, it calls the registration endpoint and receives a unique client_id and client_secret.
  4. The MCP client caches these credentials locally and uses them for all subsequent OAuth flows against your identity provider.
  5. Under the hood, Alpic proxies all token requests through the single upstream client you configured.

​
Managing your client pool

You can create, update, or delete your client pool from the Settings → Authentication tab of your project.
  • Create — set up the DCR proxy for the first time by providing your upstream client credentials. In order to have the option to setup your DCR proxy, your MCP server must reference itself as the issuer and lack a registration_endpoint.s
  • Update — change the client ID, secret, or scopes. This is safe for existing MCP clients as their issued credentials remain valid.
  • Delete — remove the client pool entirely. This is a destructive action with consequences detailed below.

​
Impact of deleting the client pool

Deleting a client pool is an irreversible operation that will break existing MCP client connections.
When you delete a client pool:
  • All dynamic client registrations are permanently removed. Every client_id / client_secret pair that was issued to MCP clients ceases to exist on Alpic’s side.
  • MCP clients still hold their cached credentials. The MCP OAuth specification mandates that clients cache their registration credentials locally. Alpic cannot invalidate or revoke those cached values.
  • Reconnection attempts will fail. When an MCP client tries to reconnect using its cached credentials, the token exchange will fail because Alpic no longer recognizes the client.
  • The registration endpoint disappears. Your server’s OAuth discovery metadata will no longer advertise a registration_endpoint, so new clients cannot register via DCR until a new pool is created.

​
When is it safe to delete?

ScenarioSafe?Why
Your server has never been used by an MCP client✅No credentials have been issued
You are decommissioning the server entirely✅No future connections are expected
You are switching to an IdP that natively supports DCR✅You’ll remove the proxy in favor of your IdP’s own registration endpoint
Your server has active users❌Existing clients will break — update the pool instead
If you need to rotate credentials or change identity providers, update your client pool rather than deleting it. Updating preserves all existing dynamic client registrations — only the upstream OAuth client credentials change. MCP clients will continue authenticating without interruption.