Setting up OAuth

The Model Context Protocol (MCP) Specification requires OAuth providers to support specific features that most existing OAuth implementations don’t provide. This guide explains the challenges and solutions for implementing OAuth authentication with MCP servers.

The OAuth challenge in MCP

The MCP Specification requires your OAuth provider to support:

• OAuth 2.1 with mandatory PKCE
• Dynamic Client Registration (DCR)
• Authorization Server Metadata
• Protected Resource Metadata

The main challenge is that most OAuth providers do not support Dynamic Client Registration (DCR). Popular providers like Google, GitHub, and Microsoft Azure AD don’t support DCR, which MCP clients need to register themselves dynamically as OAuth clients.

The DCR problem

When creating an OAuth client, the usual workflow is for the developer to manually get a client_id and client_secret from the authorization server, then configure their application with these credentials.

This traditional approach is aimed at developers, not end users. It assumes that the developer has access to the OAuth server’s management interface and can create an application manually.

The idea of end users finding your application’s OAuth registration page, filling out a form, and getting a client ID and secret is not how the MCP Specification envisions OAuth. Instead, it expects that MCP clients can dynamically register themselves as OAuth clients without manual intervention.

Here’s the crux of the issue: MCP clients have no standardized way to handle client IDs or client secrets. They need to be able to register themselves dynamically as OAuth clients to perform the authentication dance.

But here’s the thing, and it cannot be stressed enough: most OAuth providers do not support Dynamic Client Registration (and yours probably doesn’t either).

The OAuth proxy solution

Since most OAuth providers don’t support DCR, the community has developed a workaround: OAuth proxies. An OAuth proxy sits between the MCP client and your actual OAuth provider, acting as a translator that speaks “MCP OAuth” on one side and “regular OAuth” on the other.

The most popular implementation uses Cloudflare Workers, which has become the de facto standard for this architectural pattern.

How OAuth proxies work

1. The proxy exposes its own OAuth endpoints that comply with MCP requirements (including DCR support)
2. The MCP client only talks to the proxy, never directly to your real OAuth provider
3. The proxy handles all the translation between MCP’s expectations and your OAuth provider’s reality
4. The tokens the MCP client receives are generated by the proxy; they never see your actual OAuth provider’s tokens

The Cloudflare OAuth wrapper exposes endpoints like:

• /.well-known/oauth-authorization-server
• /register (for dynamic client registration)
• /authorize
• /token

Behind the scenes, the proxy stores all the mapping data in Cloudflare KV, maintains the relationship between its “fake” tokens and the real provider tokens, and handles all the complexity of token refresh and validation.

Implementation considerations

Building an OAuth proxy requires handling:

• PKCE verification (because MCP requires OAuth 2.1)
• Token lifecycle management (storing, refreshing, and revoking)
• Security considerations (you’re now responsible for token security)
• Custom adapters (for each OAuth provider you want to support)
• Performance optimization (every auth check now has additional hops)

The shared credentials pattern

Most current implementations store a single client_id and client_secret for the entire proxy. This means every user of your MCP server is effectively acting under the same OAuth application.

From the upstream OAuth provider’s perspective, there’s only one registered application, even though the proxy implements Dynamic Client Registration internally. This can lead to issues with:

• Rate limiting
• Token revocation
• Auditing and compliance
• User attribution

Example: WorkOS and Cloudflare Workers

The Cloudflare AI repository  provides several live examples demonstrating OAuth proxy implementations. The WorkOS example  illustrates how an OAuth wrapper is registered using the Cloudflare provider.

Key architectural patterns from the WorkOS example:

• The Cloudflare wrapper exposes its own complete OAuth server, including all required endpoints
• The MCP client never directly interacts with the downstream OAuth provider
• All server metadata points exclusively to the Cloudflare server
• The proxy uses Cloudflare KV for persistent storage of grant data and tokens
• Custom WorkOS adapters integrate through parseAuthRequest and completeAuthorization functions
• Users are redirected to the authentic OAuth consent screen of the underlying provider
• The proxy handles PKCE verification to maintain OAuth 2.1 security standards

Alternative approaches

Many companies claiming to support “OAuth” for their MCP servers are actually using simpler approaches:

Personal Access Tokens

Instead of implementing full OAuth flows, some providers (like GitHub’s MCP server) expect users to obtain personal access tokens separately and pass them directly in headers. This approach:

• Avoids the complexity of OAuth proxies
• Provides a simpler user experience
• Doesn’t require Dynamic Client Registration
• Is not technically OAuth, but is often more practical

Pre-configured Client Credentials

Some implementations use traditional OAuth with pre-configured client credentials, requiring users to:

1. Register an OAuth application manually
2. Configure their MCP client with the client ID and secret
3. Handle the OAuth flow through the MCP client

This approach works but requires more manual setup from users.

Architectural implications

Implementing OAuth proxies means you’re essentially building a distributed authorization server. Consider these implications:

• Additional infrastructure: The proxy needs to handle stateful operations like storing authorization codes and managing token lifecycles
• Performance impact: Every API call now involves additional hops through the proxy
• Security complexity: You’re responsible for securing the proxy infrastructure and protecting token mapping databases
• Monitoring challenges: When all users share the same OAuth application credentials, you may lose granular visibility into individual user actions

Best practices

When implementing OAuth for MCP servers:

1. Evaluate your requirements: Consider whether full OAuth is necessary or if simpler approaches like personal access tokens would suffice
2. Plan for scale: If using OAuth proxies, ensure your infrastructure can handle the additional load and complexity
3. Security first: Implement proper token rotation, secure storage, and audit logging
4. User experience: Provide clear documentation and setup instructions for users
5. Monitor and maintain: Set up proper monitoring for the proxy infrastructure and token lifecycle management

Looking forward

The MCP OAuth situation represents a fundamental tension between the protocol’s vision of seamless authentication and the realities of existing OAuth infrastructure. For now, teams implementing MCP need to carefully evaluate their authentication requirements and choose an approach that balances specification compliance with practical implementation constraints.