Cookie preferences

We use cookies to improve your experience. See our Privacy Policy.

Manufact

How to Set Up OAuth in Your MCP Servers

Andrew Khadder
Andrew KhadderEngineer
How to Set Up OAuth in Your MCP Servers

As your MCP server grows and begins to access more sensitive data, implementing authentication becomes a necessity. Using mcp-use, integrating any OAuth provider with your MCP Server is a straightforward process.

While MCP relies on Dynamic Client Registration (DCR) for authentication, many OAuth providers don't support this out of the box. For those providers, mcp-use includes an OAuth Proxy that allows you to use providers like Google or Github with ease.

How does MCP Authentication work?

If you're interested in a comprehensive deep dive into MCP authentication check out our other blog post here: MCP Authentication: A Complete Guide

Dynamic Client Registration (DCR)

Normally in a web app, your OAuth client is always the same. You pre-register it in your auth server once, give your app the client ID, and you're done. When it comes to MCP, the client constantly changes. Connecting to your MCP Server via Claude, ChatGPT, or Cursor are all examples of different clients that hit your auth server. How can you know which MCP Client is going to request authentication next?

Dynamic Client Registration enables clients, such as Claude, to automatically register with your auth server by calling /register with details like the name, redirect URIs, and grant types. The auth server provides credentials in response. With these credentials, the client can proceed with the standard OAuth flow. The client sends an authorization request with the client ID, prompting the user to login and consent, and finally receives an access token it can use to make requests to the server.

Loading diagram...

Setting up WorkOS AuthKit with mcp-use

We’re using WorkOS for this first example because it offers native support for DCR out of box. If you’re using a different provider, check out our documentation and examples repository for more details.

First, you'll need to configure WorkOS in the dashboard.

  1. Go to WorkOS Dashboard → Applications and click Create application.
  2. Go to Applications → Configuration and click Manage under Dynamic Client Registration. Enable DCR.
  3. Go to Redirects and add the redirect URIs where AuthKit will send users after login.

Now this is all the code you need to set up WorkOS with mcp-use:

import { MCPServer, oauthWorkOSProvider } from "mcp-use/server"; const server = new MCPServer({ name: "my-server", version: "1.0.0", oauth: oauthWorkOSProvider({ subdomain: "my-company.authkit.app" }), }); server.tool( { name: "get-user-info", description: "Get information about the authenticated user", }, async (_args, ctx) => object({ userId: ctx.auth.user.userId, email: ctx.auth.user.email, name: ctx.auth.user.name, }) );

Note: By default, WorkOS JWTs only contain the user ID. To access email and name in ctx.auth.user, you'll need to set up a JWT template in the WorkOS Dashboard under Sessions → JWT Templates and include those claims explicitly.

OAuth Proxy

If your OAuth provider does not yet support Dynamic Client Registration (DCR), you can utilize the OAuth Proxy provided by mcp-use. This proxy allows you to still use the provider by mediating the OAuth flow with pre-configured credentials instead of directly registering with the authorization server.

For the client, the process appears to be standard DCR. However, when the client sends a request to the /register endpoint, the proxy returns your pre-configured client ID, satisfying the DCR expectation.

Loading diagram...

For example, to use the OAuth Proxy with Auth0, first create a regular web app in the Auth0 Dashboard. Go to Auth0 Dashboard → Applications → Create Application, select Regular Web App, and note down your client_id and client_secret. Then go to Settings and add your redirect URIs under Allowed Callback URLs.

Once that's done, your entire server setup looks like this:

import { MCPServer, oauthProxy, jwksVerifier, object, error } from "mcp-use/server"; const domain = process.env.AUTH0_DOMAIN; const clientId = process.env.AUTH0_CLIENT_ID; const clientSecret = process.env.AUTH0_CLIENT_SECRET; const audience = process.env.AUTH0_AUDIENCE ?? ""; const server = new MCPServer({ name: "auth0-proxy-example", version: "1.0.0", oauth: oauthProxy({ authEndpoint: `https://${domain}/authorize`, tokenEndpoint: `https://${domain}/oauth/token`, issuer: `https://${domain}/`, clientId, clientSecret, scopes: ["openid", "email", "profile"], extraAuthorizeParams: { audience }, verifyToken: jwksVerifier({ jwksUrl: `https://${domain}/.well-known/jwks.json`, issuer: `https://${domain}/`, audience, }), }), }); server.tool( { name: "get-user-info", description: "Get information about the authenticated user from the JWT", }, async (_args, ctx) => object({ userId: ctx.auth.user.userId, email: ctx.auth.user.email, name: ctx.auth.user.name, picture: ctx.auth.user.picture, scopes: ctx.auth.scopes, }) ); server.listen();

When using the OAuth proxy, you need to provide a verifyToken function so mcp-use knows how to validate the tokens your provider issues. If your provider issues standard JWTs, the built-in jwksVerifier helper handles this automatically.

Wrapping Up

As agents continue to access more sensitive data, securing what they can reach is critical. With mcp-use, adding OAuth support only takes a few lines and ensures that your server can authenticate with any MCP client.

If you want to explore further, check out the mcp-use examples and documentation for all supported providers and configuration options.

References

Share

Get Started

What will you build with MCP?

Start building AI agents with MCP servers today. Connect to any tool, automate any workflow, and deploy in minutes.