Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mcp-use.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

Server Authentication

Add enterprise-grade OAuth 2.0/2.1 authentication to your MCP server. Secure your tools with bearer token authentication, implement role-based access control (RBAC), and access authenticated user information in your tool callbacks.

Quick Start

Use a built-in provider when your identity provider supports remote authentication. Clients register and authenticate directly with the upstream provider — your server only verifies the resulting bearer token.
import { MCPServer, oauthWorkOSProvider } from 'mcp-use/server'

const server = new MCPServer({
  name: 'my-secure-server',
  version: '1.0.0',
  oauth: oauthWorkOSProvider({
    subdomain: process.env.MCP_USE_OAUTH_WORKOS_SUBDOMAIN!, // 'your-company.authkit.app'
  })
})

server.tool({
  name: 'get-user-profile',
  description: 'Get the authenticated user profile',
  cb: async (params, context) => {
    const user = context.auth.user
    return { userId: user.userId, email: user.email, name: user.name }
  }
})

await server.listen(3000)

Providers

Not sure which to use? Use a remote auth provider if your identity provider supports Dynamic Client Registration. If it doesn’t, use oauthProxy.

Remote Auth (built-in)

Clients register and authenticate directly with the provider.
  • Auth0 — Full OAuth 2.1 with PKCE and JWKS verification
  • Better Auth — Self-hosted OAuth 2.1 via the Better Auth OAuth Provider plugin
  • WorkOS — Enterprise SSO via WorkOS AuthKit
  • Supabase — Authentication for Supabase projects
  • Keycloak — Enterprise SSO with realm roles
  • Custom Provider — Any DCR-capable provider with a custom verifyToken function

OAuth Proxy

For providers that don’t support remote client registration — Google, GitHub, Okta, Azure AD, or any provider where you register an application in a dashboard and receive a fixed clientId/clientSecret — use oauthProxy:
  • OAuth Proxy — Bridge non-DCR providers with pre-registered client credentials, including ready-to-copy configs for Google, Okta, Azure AD, Auth0, and GitHub.

How it works

Remote auth flow

  1. Your server exposes .well-known/* endpoints that pass through the upstream provider’s OAuth metadata — including its registration_endpoint.
  2. MCP clients fetch that metadata, register themselves directly with the upstream provider, then run the full authorization + token exchange against it.
  3. On each /mcp/* request, your server verifies the bearer token (JWKS signature check, issuer, audience).

OAuth proxy flow

  1. Your server exposes a /register endpoint that returns your pre-configured clientId.
  2. MCP clients run PKCE authorization against the upstream using that clientId.
  3. At token exchange, your server injects the clientId and clientSecret before forwarding to the upstream.
  4. On each /mcp/* request, your server verifies the bearer token via the verifyToken function you provided.
Your server holds the client credentials and mediates every token exchange.

OAuth Endpoints

When OAuth is configured, your server exposes these discovery endpoints:
GET /.well-known/oauth-authorization-server
GET /.well-known/openid-configuration
GET /.well-known/oauth-protected-resource
GET /.well-known/oauth-protected-resource/mcp
The authorization-server endpoints pass through the upstream provider’s metadata so clients can discover the real authorize, token, and registration URLs.

Bearer Token Authentication

All /mcp/* endpoints require a valid bearer token when OAuth is configured:
Authorization: Bearer eyJhbGci...

Next Steps