Auth for MCP Servers

For developers building applications that use AI agents to interact with external systems, standardizing how these agents call tools is a significant challenge. The Model Context Protocol (MCP) provides a specification for this interaction. This guide gives a technical overview of MCP and explains how to implement robust authentication and authorization for MCP servers using Auth0.

What is the Model Context Protocol (MCP)?

MCP is an open standard, developed by Anthropic, that specifies a common interface for AI agents and Large Language Models (LLMs) to communicate with tools. It’s designed to solve the problem of tool discovery and interaction in a standardized way. MCP supports networked environments using HTTP and Server-Sent Events (SSE), allowing an AI agent to interact with tools hosted on remote servers across the internet.

For developers building AI applications, MCP offers practical advantages:

• Standardized Interfaces: MCP provides common patterns for tool definitions. This reduces the need for custom integration code for each LLM provider, allowing you to swap backends to optimize for cost or performance with less refactoring.
• LLM-Optimized Tool Definitions: The protocol acknowledges that APIs for LLMs differ from traditional developer APIs. LLM-facing tools require richer descriptive context and metadata for the model to use them effectively, a distinction MCP incorporates into its design.
• Reusable Components: Growing adoption means access to a larger ecosystem of MCP-compliant tools and resources. This allows developers to leverage existing, tested components rather than building everything from scratch.

Authentication and Authorization for MCP Servers

When an MCP server is exposed to the internet, it must be secured. The MCP specification recommends using OAuth 2.1 to secure these interactions. This allows an MCP server to delegate authentication to a dedicated authorization server and manage access control for different clients, users, and actions using scopes.

Mandatory Server Configuration

For a client to interact with your server, the MCP specification requires you to announce your authorization configuration and use standard HTTP responses.

1. Announce Your Auth Server with Protected Resource Metadata (RFC 9728)

Your MCP server must tell clients where to get authorized. To do this, you must expose a metadata endpoint. Create a .well-known/oauth-authorization-server endpoint on your server that returns a JSON object pointing to your Auth0 tenant. This allows MCP clients to automatically discover your authorization endpoints without manual configuration.

2. Use the WWW-Authenticate Header for 401 Errors

When a client makes a request without a valid token, your server must return a 401 Unauthorized status. Crucially, this response must include the WWW-Authenticate header, pointing to the metadata URL you configured above. This signals to the client that authentication is required and tells it exactly where to start the process.

Implementing MCP Security with Auth0

By using Auth0 as your authorization server, you can secure your MCP server without building and maintaining a complex identity system yourself. The MCP specification highlights several key OAuth 2.1 features that Auth0 provides:

• Proof Key for Code Exchange (PKCE): PKCE mandatory security feature that mitigates authorization code interception and is handled automatically in Auth0’s SDKs.
• Metadata Discovery: Is mandatory per the MCP spec. Servers must advertise their OAuth endpoints. An Auth0 tenant provides an authorization server discovery document (/.well-known/oauth-authorization-server) so MCP clients can dynamically find the required endpoints for authorization, token exchange, etc., reducing manual client-side configuration.
• Dynamic Client Registration (DCR): DCR is crucial for scalability. It allows MCP clients (like a generic AI workbench) to programmatically register with your Auth0-secured MCP server via an API call. This avoids forcing users to manually create a client application in the Auth0 Dashboard for every new tool they want to connect.
• Delegating Authentication to a Third-Party Identity Provider(IdP): The specification supports delegating the user login process. You can configure your MCP server to use Auth0 as the trusted identity provider, centralizing user management and sign-on logic.

MCP Authorization Flow with Auth0

Here is the standard OAuth authorization code flow when an MCP server uses Auth0 as its authorization server:

1. The MCP client initiates the OAuth flow by making a request to the MCP server’s authorization endpoint.

2. The MCP server redirects the user to the Auth0 authorization server.

3. The user authenticates with Auth0 (using username/password, social login, or MFA).

4. After successful authentication, Auth0 redirects the browser back to the MCP server’s callback URL with a single-use authorization code.

5. The MCP server exchanges the authorization code for an access token directly with the Auth0 token endpoint.

6. The MCP server validates the token from Auth0 and generates its own session or internal access token that is bound to the third-party session.

7. The MCP server completes the original OAuth flow, returning its own token to the MCP client, which can then be used to make authenticated calls to the server’s tools.

Access Token Validation

Receiving a token is not enough. Your MCP server must validate every token to ensure it is authentic and intended for your server. This involves several checks:

• Verify the Token Signature: Check that the token was signed by Auth0.
• Check the Expiration Time (exp claim): Ensure the token has not expired.
• Validate the Audience (aud claim): This is the most important check. Verify that the aud claim exactly matches your server’s unique identifier.
• Verify the Issuer (iss claim): Check that the token was issued by your Auth0 tenant.

Auth0’s SDKs can perform these checks automatically. You apply this validation as a middleware to your protected routes.

Security Best Practices: Sessions and Requests

1. Do Not Use Sessions for Authentication The MCP specification prohibits using sessions for authentication. The bearer access token is the only valid credential. You must verify the access token on every single inbound request to a protected endpoint. This stateless authentication model is more secure and prevents session hijacking attacks.

2. Verify All Inbound Requests Security is a continuous process. Explicitly state in your documentation that all inbound requests to tool endpoints must be verified to contain a valid, validated access token. Use middleware (like the one that performs the token validation) to protect every relevant route.

For more best practices check out the MCP official Security Best Practices page.