Authenticating MCP servers: the OAuth reality, DCR gaps, and proxy workarounds

MetaMicrosoftNewsPerformance

OAuth meets MCP: proxies to the rescue

Most MCP clients and enterprise OAuth stacks are talking past each other: the MCP Specification mandates OAuth 2.1 with PKCE and Dynamic Client Registration, but mainstream providers rarely support DCR. Teams are bridging the gap with OAuth proxies—often on edge runtimes—that mint “proxy tokens,” handle PKCE, and translate flows to legacy providers. It works, but introduces security, performance, and compliance trade-offs you’ll want to plan for before rollout.

Points clés

  • The MCP Specification expects OAuth 2.1 with PKCE, Dynamic Client Registration (DCR), authorization server metadata, and protected resource metadata.
  • In practice, most MCP clients look for /.well-known/oauth-authorization-server at the MCP server domain, not /.well-known/oauth-protected-resource.
  • DCR is the primary blocker: major providers (e.g., Google, GitHub, Microsoft Azure AD) generally do not support it.
  • As a result, teams deploy OAuth proxies that expose MCP-compliant endpoints and translate to their existing OAuth provider.
  • The de facto pattern uses edge runtimes (e.g., Cloudflare Workers) and stores grants, codes, and provider tokens in key-value stores (e.g., Cloudflare KV).
  • Tokens presented to MCP clients are proxy-issued “fake” tokens, not the underlying provider’s tokens.
  • Most “DCR” implementations are a façade: a single clientid/clientsecret powers the proxy for all users, creating shared app identity upstream.
  • GitHub’s remote MCP server explicitly does not support DCR and advises passing personal access tokens directly in headers.
  • A reference example pairs WorkOS with a Cloudflare-based OAuth wrapper using custom adapters and PKCE verification.
  • The page notes increased operational burden (token lifecycle, security hardening, logging, auditing) and was last updated on November 5, 2025.

À retenir

Want MCP auth without the migraine? Start simple: if your use case allows, pass tokens in headers and skip the dance. If you need “real” OAuth, pilot a proxy in a tight scope, document the “one app for everyone” reality, lock down token storage, and upgrade your logging so audits don’t look like “one mystery app did everything.” And yes, keep asking your IdP about DCR—someday they might say yes. Until then, proxies are your friend (the needy, high‑maintenance kind).

Sources