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.
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.
- Go to WorkOS Dashboard → Applications and click Create application.
- Go to Applications → Configuration and click Manage under Dynamic Client Registration. Enable DCR.
- 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:
Note: By default, WorkOS JWTs only contain the user ID. To access
nameinctx.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.
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:
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.







