Understanding MCP

MCP authorization

Authorization in the world of AI tools is changing. As more systems interact with language models, security and access control have become core parts of the infrastructure. Model Context Protocol (MCP) is a newer standard that connects large language models (LLMs) to tools and data sources. With that, MCP authorization has emerged as a specific area worth understanding.

This article explains how MCP handles authorization and what it means when building or operating an MCP server. It also covers the differences between authentication and authorization, the structure of MCP servers, and how OAuth 2.1 fits into the process.

Whether working with AI agents or configuring access to APIs, clear authorization rules are important. Here is how MCP handles them.

What is MCP authorization?

MCP authorization is the process of verifying whether a user or client has permission to access and use tools or data exposed by an MCP server. It works by using access tokens, which are issued by an authorization server and validated by the MCP server before any tool is used.

The Model Context Protocol (MCP) is an open protocol that standardizes how tools and context are exposed to large language models. It defines how servers share capabilities, how clients connect, and how tools are called.

MCP servers use OAuth 2.1 to authorize access. In this setup, the MCP server acts as a resource server. A resource server is a system that hosts protected data or tools and checks each request to make sure the access token is valid and authorized.

Authentication confirms who someone is, while authorization determines what they can access or do. In MCP, both may be involved, but authorization is what controls access to server-side tools.

Authorization is part of every request in a protected MCP environment. The server checks the token to ensure it's valid, not expired, and was issued for that specific server. If it passes all checks, the server processes the request.

Core authentication methods for MCP servers

MCP servers support multiple authentication methods, each with different trade-offs:

• OAuth 2.1: The standard method recommended by the MCP specification. It's secure and flexible but more complex to implement.

• API Keys: Simple string tokens that identify and authorize the client. Easy to use but offer less control over permissions.

• Custom Schemes: Authentication methods designed for specific needs, like integrating with legacy systems.

OAuth 2.1 is the primary method used in MCP server authorization. The MCP server acts as a resource server and accepts access tokens issued by an authorization server. The token arrives in the Authorization header and is validated before allowing access to MCP tools.

The OAuth flow works like this: clients redirect users to the authorization server, obtain an authorization code, and exchange it for an access token. This token is then sent with each request to the MCP server.

API keys are static strings used to authenticate requests. They're commonly used in internal setups or low-risk environments. The key is passed with each request and validated by the server. While simple to implement, they don't support fine-grained scopes or expiration.

Role and permission design for MCP

MCP servers allow users and AI agents to interact with tools. To control who can access which tools, role-based access control (RBAC) is used. RBAC assigns permissions to users based on their roles, with each role having specific actions it can perform.

Permission granularity refers to how detailed these permissions are. A granular system can control access at the level of individual tools or actions, preventing unauthorized access and limiting tool usage to what's necessary for each user.

A typical permission hierarchy includes roles like:

• Admin: Can use all tools and change server configurations

• Developer: Can use development-specific tools and access logs

• User: Can use common model tools but cannot change settings

• Read-only: Can see tool outputs but cannot run or modify tools

Each role is defined based on the user's responsibilities and the sensitivity of the tools involved. This structure allows the MCP server to check user roles and apply the correct permissions before allowing access to tools.

Steps to implement OAuth 2.1 in MCP

Implementing OAuth 2.1 in an MCP server involves several key steps:

1. Register the application

First, register the MCP server as a client with the authorization server. This generates a client ID and client secret that identify the MCP server during the OAuth process. The registration includes redirect URIs (where users are sent after approving access) and defines which grant types and scopes the server will support.

2. Configure scopes and redirects

Configure OAuth scopes to represent the actions users or agents can perform. For MCP tools, common scopes include tool:read to fetch tool information and tool:write to invoke tools. Redirect URIs must be registered exactly as they appear in the client configuration, using secure HTTPS to prevent interception.

3. Obtain and validate tokens

After the user authorizes access, the authorization server issues an access token. The MCP server validates this token to determine whether the request is valid. This includes checking the token's signature, expiration time, and required scopes.

import jwt

def validate_token(token, public_key):
    try:
        payload = jwt.decode(token, public_key, algorithms=["RS256"])
        # Check for required scopes and claims
        if "tool:read" in payload.get("scope", []):
            return True
    except jwt.ExpiredSignatureError:
        return False
    return False

4. Enforce role-based access

Access to MCP tools is controlled by inspecting claims in the access token. Claims such as role or permissions describe what the user is allowed to do. If the token includes a role claim with the value "admin," the server can allow access to administrative tools. If the role is "user," the server can limit access to standard tools.

Using authentication context in a MCP server

MCP servers process requests that include authentication tokens containing information about the user or system making the request. This information is called the authentication context.

The authentication context helps make decisions about access and behavior in the server. For example, the server can verify the user's identity, check their role, or evaluate other claims stored in the token. This allows the server to control which tools are available and how they respond.

Tokens used in MCP authorization are often JSON Web Tokens (JWTs). These tokens contain claims—key-value pairs that describe the user. Common claims include:

• sub: A unique identifier for the user

• role: The user's assigned role

• scope: What actions the token allows

• exp: When the token expires

MCP servers can make dynamic decisions based on these values. For example, checking the user's role to determine if they can run a tool, or inspecting other factors like time of day or IP address. If a tool is restricted to certain hours or regions, the server can return an error or hide the tool.

Integrating external identity providers with MCP

An MCP server can use external identity providers to handle user authentication and authorization. This delegates credential management, login flows, and token issuance to a system that follows OAuth 2.1 or OpenID Connect standards.

To integrate with Auth0:

1. Register the MCP server as a new application in the Auth0 dashboard

2. Define allowed callback URLs where Auth0 will redirect users after login

3. Use Auth0's JWKS endpoint to validate incoming access tokens

For Azure AD integration:

1. Register the MCP server as an application in the Azure portal

2. Set up API permissions for the application

3. Use Azure AD's OpenID Connect metadata to discover authentication endpoints

Custom identity providers need to support either OAuth 2.1 or OpenID Connect, expose a public key endpoint for token verification, and document any custom claims or token formats used.

Troubleshooting common MCP authorization errors

When working with MCP authorization, some errors occur more frequently than others:

1. Invalid or expired tokens

This happens when the MCP server cannot verify the access token sent by the client. Common causes include:

• Clock skew: When client and server system clocks aren't synchronized

• Token expiration: The token has passed its expiration time

• Token revocation: The authorization server has invalidated the token

To handle expired tokens, clients may request a new token using a refresh token, if supported. If the refresh token has also expired, the client must restart the authorization flow.

2. Scope mismatch problems

OAuth tokens include one or more scopes defining what actions the token allows. If the client requests a tool that requires a scope it doesn't have, the MCP server responds with a 403 Forbidden error.

Scope mismatch errors can occur if:

• The client forgets to request the correct scope

• The requested scopes aren't registered with the authorization server

• The MCP server expects a specific format that doesn't match the token

To diagnose scope issues, inspect the access token payload and compare the scopes it contains with those required by the MCP server.

3. Misconfigured redirect URLs

Redirect URI errors happen during the OAuth authorization flow when the authorization server tries to send the user back to the client. If the redirect URI doesn't match exactly with what was registered, the server blocks the request.

This mismatch can result from typos, case sensitivity, or missing parameters in the URI. Even small differences, such as a trailing slash or missing HTTPS, can cause issues.

Streamlining MCP authorization with Stainless

At Stainless, we've built a platform that automatically generates MCP servers with built-in authorization support. Our experience converting OpenAPI specs to MCP servers showed us that authorization is one of the trickier aspects to get right.

When we generate an MCP server, we apply defaults that align with the security expectations of the MCP spec. Each server is configured to accept access tokens through the Authorization header and validate them against a public key. These servers also expose protected tools based on claims like scope and role in the token payload.

This approach reduces the time it takes to implement an authorization flow. Instead of building token validation, scope checking, and access control from scratch, we provide all of these components as part of the server template. Developers can focus on defining tools and roles without managing the lower-level protocol behavior.

Our generated servers support easier updates by tracking changes in the underlying MCP specification. When the spec evolves to include new authorization features or security changes, we update our code generation logic to match. This helps maintain compatibility with MCP clients and LLM hosts over time.

To try MCP server generation with authorization support, visit https://app.stainlessapi.com/signup.

FAQs about MCP authorization

How does MCP authorization differ from standard API authorization?

MCP authorization uses contextual information to decide whether a request has access to specific tools, while standard API authorization typically controls access to fixed endpoints like URLs or routes. In MCP, the focus is on giving permission to specific tools or actions, often based on user roles or scope claims in a token.

What security certifications are relevant for MCP authorization implementations?

MCP authorization implementations typically follow industry standards for data security and privacy, including SOC 2 for service organization controls, ISO 27001 for information security management, and GDPR when handling personal data of individuals in the EU.

Can I use the same authorization server for both my API and MCP server?

An authorization server used for APIs can also be used for MCP servers if it supports OAuth 2.1 flows and can issue tokens with the correct claims. The tokens must include scopes and audience values that match the MCP server's requirements.

How do I handle authorization for AI agents accessing my MCP server?

AI agents can be treated as clients and given their own credentials and access tokens. These tokens should include only the scopes and permissions required for the tools the agent is allowed to use, with the same security controls applied to AI agents as to human users.