Add OAuth to an MCP server

This guide demonstrates how to configure authentication for MCP servers using different OAuth methods.

From March 2025, the MCP specification began recommending OAuth-based authentication. However, most existing OAuth implementations don’t meet MCP requirements . The specification calls for OAuth 2.1 and support for Dynamic Client Registration (DCR), which most major OAuth providers — including Google, GitHub, and Microsoft Azure AD — don’t support. This mismatch between MCP’s vision and existing OAuth infrastructure creates a common implementation barrier for enterprise adoption.

Gram bridges this gap by supporting multiple authentication approaches, from simple token-based methods to complex OAuth proxy solutions. How you set up authentication depends on the OAuth capabilities of your underlying API and the intended purpose of your MCP server. Understanding these different approaches and their trade-offs is essential for selecting the right authentication strategy.

Using the Authorization Code Flow

The Authorization Code Flow enables user-interactive OAuth with proper consent screens. However, it requires OAuth providers to support specific MCP requirements.

With DCR

If you want to host an MCP server for large-scale use by external developers, you should plan to build out support for DCR.

For example,Stripe  and Asana  have both added support for DCR to their APIs to accommodate MCP.

If the API is already configured to support DCR, enabling the Authorization Code Flow on Gram is simple:

• Create a manifest file for the OAuth server in Gram.
• Attach the manifest to your toolset.

Without DCR

Because most APIs don’t support DCR, Gram offers an OAuth proxy that translates between MCP requirements and standard OAuth implementations. The proxy uses a specific client ID and secret to access the API on behalf of the MCP server end users.

This is useful for MCP servers that won’t be exposed to the public, or in cases where a server acting as a single client_id is acceptable.

For example, the Cloudflare OAuth proxy  doesn’t support DCR.

The OAuth proxy works using the following mechanisms:

• Proxy registration: The proxy exposes DCR-compliant endpoints to MCP clients.
• Token translation: It converts proxy tokens to a set of real provider tokens.
• Flow management: It handles the OAuth dance between the client and the actual provider.
• State storage: It maintains token mappings and authorization state.

If you want to implement an OAuth proxy in Gram, please book time with our team . We’ll get you up and running.

Using the Client Credentials grant

The Client Credentials grant is a simpler authentication method. The server exchanges a client ID and secret for access tokens. Gram handles the token exchange process automatically.

Implement the Client Credentials grant in Gram as follows:

• Upload the OpenAPI document to Gram
• Navigate to the Environments tab
• Add the CLIENT_ID (application client identifier) and CLIENT_SECRET (application client secret) environment variables.
• Attach the environment to your toolset.

Using access token authentication

Access token authentication allows passing pre-obtained tokens directly to the MCP server. This method works with any OAuth provider, regardless of DCR support.

Implement access token authentication in Gram as follows:

• Obtain the access token from your OAuth provider.
• Navigate to the Environments tab.
• Add the ACCESS_TOKEN environment variable.
• Attach the environment to your toolset.

Popular services like GitHub use this approach. While technically OAuth-based, no OAuth flow occurs through the MCP client.