How authentication actually works between AI clients and MCP servers, why enterprise IdPs are a challenge, and what you can do about it today.
December 2025 | Based on MCP Spec 2025-11-25
The gap: MCP assumes dynamic, automatic client registration. Enterprise IdPs assume manual, pre-approved app onboarding. These models are fundamentally incompatible.
The bridge that makes non-DCR IdPs work with MCP today
MCP client calls /register on the proxy. Proxy accepts the dynamic callback URL and returns its pre-configured upstream credentials.
You register the proxy once with your IdP. The proxy then handles unlimited MCP client connections using those fixed credentials.
Proxy maintains separate PKCE flows with client and IdP. Issues its own JWTs that reference upstream tokens. Full security at both layers.
Claude sends its dynamic callback URL (e.g., http://localhost:54321/callback). Proxy stores this and returns its pre-configured client_id from the upstream IdP.
Client hits /authorize. Proxy stores client's PKCE challenge, generates its own PKCE for upstream, shows consent screen, then redirects to IdP using proxy's fixed callback URL.
IdP redirects to proxy's callback. Proxy exchanges auth code for upstream tokens, encrypts and stores them, generates a new auth code for the client.
Proxy redirects to client's original dynamic callback. Client exchanges its code for a proxy-issued JWT that references the upstream token. Done.
| Approach | Who Handles DCR? | Enterprise IdP? | Status |
|---|---|---|---|
| OAuth Proxy (FastMCP) | Proxy presents DCR facade | ✓ Via fixed creds | Production |
| DCR-Native Provider WorkOS, Auth0, Stytch |
Provider (native DCR) | ✓ Via OAuth bridge | Production |
| Manual Client ID | N/A (pre-registered) | ✓ Direct | Available |
| CIMD Client ID Metadata Docs |
Client hosts metadata URL | ✓ Domain-based trust | VSCode only |
| Cross App Access SEP-990 |
N/A (IdP controls all) | ✓ Native | Draft |
For enterprises today: Use OAuth Proxy (FastMCP) or a DCR-native provider (WorkOS). Both work now with existing IdPs.
The Nov 2025 MCP spec introduced two major changes to client registration
Client ID Metadata Documents - the new default
https://app.com/client.jsonEnterprise-Managed Authorization (SEP-990)
CIMD flips the registration model: instead of clients registering at servers, servers fetch client metadata from URLs. This eliminates the database sprawl problem that plagued DCR.
A pragmatic path forward while the auth landscape matures
The recommendation: See how far you can get with unauthenticated servers first. Build the muscle. When the auth story matures, you'll be ready to unlock sensitive use cases with confidence.
Questions? Just ask.