OAuth for MCP Explained
OAuth is the required authorization framework for all Model Context Protocol (MCP) servers that use HTTP for transportation, and a clear understanding of how OAuth works has become critical to building and deploying MCP servers.
However, a quick survey of forums and articles will reveal that OAuth can become complex and fraught with difficulties when applied between MCP servers and clients.
Many people building MCP servers are still unclear on how OAuth works and why it isn’t working for them. This lack of understanding can lead to inadequate implementation, potentially compromising not only usability but also security.
In this blog, I give you everything you need to know about OAuth as it relates to MCP, including a step-by-step guide to the MCP OAuth flow, and why an MCP gateway like MCP Manager is the best way to add authorization, authentication, and identity management for enterprise use of MCP servers and AI.
What is OAuth?
OAuth is an authorization framework that enables a website or application to access protected resources (such as another application or a database) on behalf of a user, without requiring the user to share their credentials.
OAuth works by issuing temporary tokens that give an application access to the resource. A secondary server (the authorization server) issues tokens.
These tokens are “scoped,” meaning they have a specific level of access for a set period.
You can think of OAuth as giving someone a keycard that allows temporary access to specific parts of a building, instead of giving them a real key and hoping they only access designated areas and return the key after completing their task. It also means you can easily deactivate that keycard (or token) if it comes into the possession of someone else.
OAuth handles authorization, granting access, but does not verify a user’s identity (authentication).
What are the benefits of OAuth?
OAuth enables you to provide applications with temporary access to protected data and resources using access tokens that:
- Provided time-limited access
- Are revocable
- Don’t require sharing of credentials with third parties
- Provide specific access to data and resources
- Reduce the need for multiple passwords and logins across different services
Besides the security benefits above, OAuth is also the go-to because it is already widely used, interoperable, scalable, and flexible. Using OAuth also means that developers don’t need to create and maintain their own authorization mechanism.
What is the Model Context Protocol (MCP)?
The Model Context Protocol is an open standard, open-source framework that standardizes how AI, particularly large language models (LLMs), access and utilize resources, including applications, databases, and services.
MCP enables people and organizations to connect LLMs to tools and resources using a universal connection and communication protocol, rather than creating bespoke integrations for each resource.
In MCP environments, an LLM, or MCP client, connects to an MCP server, which provides a range of “tools” to the client.
For example, an email client’s MCP server could include tools for drafting and sending emails, calendar management, and summarizing the day’s meetings ahead, or emails received that day.
Essentially, MCP acts as the USB port for LLMs, enabling easy connection of AI agents to any application, database, or other resource, thereby releasing the promised potential of enterprise AI. By early 2025, more than 1,000 MCP connectors were already available.
Why is OAuth particularly beneficial when using the Model Context Protocol (MCP)?
MCP servers open the door to seamless integration between LLMs and your applications and data. However, an array of security risks has emerged through that open door, ranging from unintended actions by confused AI agents, through to risks directly from malicious or poorly designed MCP servers.
OAuth addresses many of the security gaps that MCP environments have. OAuth scopes LLMs’ and AI agents’ access to data, and how long that access lasts. It uses a system of tokens rather than sharing credentials directly, and enforces a robust authorization and authentication flow in those MCP environments.
Is OAuth Part of the Model Context Protocol?
As per the MCP specification, authorization is optional for MCP implementations.
However, implementations using an HTTP-based transport (as opposed to STDIO and other alternative transport methods) and that support authorization must use OAuth.
The MCP specification also includes other directives around how OAuth must and should work in MCP implementations, including:
- MCP clients MUST implement Proof Key for Code Exchange (PKCE)
- All authorization server endpoints must be served over HTTPS
How Does The OAuth Flow Work In MCP?
- The MCP client sends an access request to the MCP server
- MCP server responds with 401 Unauthorized status
- Client fetches server metadata with authorization details
- User provides consent for the authorization server to provide an access token to the client
- The authorization server provides an access token to the client
- The client repeats step one, sending an access request to the MCP server – this time with an access token – and is granted access to the protected resource
Roles
The MCP client acts as an OAuth 2.1 client, making access requests to protected resources on behalf of the resource owner (the user).
The MCP server acts as an OAuth 2.1 resource server, granting access to protected resources to clients when the client presents a valid token and performs PKCE.
The authorization server issues access tokens, which the MCP client can use to access protected resources via the MCP server.
The resource owner (typically a user) authenticates the request using their credentials and provides consent for the authorization server to provide access tokens to the client.
Can the MCP server be the resource server and the authorization server?
There have been MCP servers launched that act as both the resource server and the authorization server. The MCP specification (at time of writing) states that the authorization server “may be hosted with the resource server or a separate entity.”
However, using the same server as the resource and authorization server goes against best practices for OAuth implementation and creates several issues when scaling up MCP servers for organizational (enterprise) use.
Using a separate authorization and resource server is the best approach, as it:
- Keeps resource servers free of complex security code
- Centralizes OAuth and other security procedures
- Allows organizations to integrate MCP use into existing Identity Provider platforms and security infrastructure
- Ensures a consistent OAuth approach and standard across all MCP servers used
The OAuth Flow in MCP – Step By Step Details
Step 1: The Initial Request
The MCP client attempts to access a protected resource by calling a protected endpoint, but it doesn’t have an access token.
Step 2: Server Responds
The MCP server sends a 401 Unauthorized status, informing the client that it needs authorization to access this resource, along with a WWW-Authenticate header that describes the authentication methods supported by the server.
The status may also include additional information for the client on how to authenticate and details on why authorization failed.
Here’s an example:
WWW-Authenticate: Bearer realm=”example”, error=”invalid_token”, error_description=”The access token expired”
Or simply:
WWW-Authenticate: Bearer
Step 3: Client Fetches Metadata
The MCP client fetches metadata from the MCP server at the /.well-known/oauth-protected-resource endpoint. The metadata (JSON) provides information about the resource server, including:
- Resource identifier (URI)
- List of trusted authorization servers that can authorize access
- Supported bearer token methods
- Supported scopes (permissions)
The client then fetches the authorization server metadata at the /.well-known/oauth-authorization-server endpoint on the specified authorization server. The JSON from the authorization server gives the client details on how to perform authorization, including:
- Authorization Endpoint: The URL to which the client directs the user to start authorization and obtain consent
- Token Endpoint: The URL where the client exchanges the authorization code for an access token
- Scopes Supported: The scope values the server supports and can enforce (such as whether I can request a token limited to read-only permissions)
- PCKE Methods Supported: In Proof Key for Code Exchange (PKCE) methods, the client generates a secret during each authorization request. This secret is used as an added verification method (along with the authorization code) when requesting access tokens to prevent attackers from using intercepted authorization codes to gain access.
Step 4: User Consent
The client opens the user’s browser to the authorization endpoint, with parameters such as:
- Response_type=code (request authorization code)
- Client_id (from registration or pre-configured)
- Redirect_uri (where the authorization server returns the code)
- Scope (permissions requested, e.g., todos.read)
- Code_challenge and code_challenge_method (for PKCE security)
- State (random string for CSRF protection)
The user signs in (authenticates) – if required – using their username and password or SSO, and provides consent for the specific permissions granted to this agent and the data it can access.
If the user provides consent, the authorization server redirects the user’s browser to the specified “redirect_uri”, with an authorization code and state in the URL.
Step 5: Codes Exchanged for Tokens
The MCP client requests access tokens from the authorization server’s token_endpoint, using an HTTP POST request that includes:
- The authorization code
- PKCE code verifier
- Redirect URI
- Client ID
- Client secret
- Grant type
Assuming the request and parameters are valid and correct, the server responds with an access token, which is typically provided as a JWT. Sometimes, a refresh token is also issued, allowing the client to obtain new tokens with the user’s (or resource owner’s) involvement.
Step 6: Client Uses Token To Access Resources
The client can now use the token to request access via the resource server (repeating step one above). Now, if the request is correct and the token has not expired, the resource server will allow the client access to the protected resource, with the scopes specified in the token.
Do MCP Servers Come Equipped For OAuth?
Not all MCP servers come equipped with OAuth, because the current specification of the Model Context Protocol does not mandate authorization.
However, the MCP specification stipulates that if the server uses HTTP as a transportation method then it must use OAuth.
Likewise, even if the server does not use HTTP but supports authorization, it must use OAuth.
OAuth implementation in MCP server flows is notoriously challenging, with numerous posts in forums from MCP server developers seeking help after repeatedly trying and failing to get their OAuth flow working correctly.
Given the amateurish nature of many OAuth implementations in MCP servers, and the patchy coverage of authorization generally across MCP servers, many organizations opt to use a secondary authorization solution, or centralize authorization, authentication, and identity management through an MCP gateway.
How To Use OAuth With MCP Servers That Aren’t Readily Equipped
If you want to use MCP servers that do not support OAuth, you can use an MCP proxy or gateway to impose the authorization flow between MCP clients and servers.
In such a setup, the MCP gateway handles the OAuth authorization flow as part of its mediation of traffic, requests, and responses between MCP clients and servers.
Using a gateway to centralize your OAuth flows has several advantages, including:
- Trustworthy OAuth flows that are consistent across all servers
- Comprehensive enterprise-level, end-to-end logging for observability and troubleshooting
- Single point of maintenance and management of OAuth flows and tokens
- Provision identities for MCP server use, including distinct identities for AI agents
- Enterprise-level oversight with the ability to monitor and revoke tokens at scale
- Strengthens the OAuth process, and the storage of tokens and secrets
Enforcing OAuth For MCP at Enterprise-Level
OAuth is becoming much more common in MCP server configurations. Unfortunately, the deployment of OAuth varies across MCP servers, and in many instances, neither abides by OAuth best practices nor MCP security best practices.
In order to bring MCP server security up to the level of other tools and applications that enterprises use, they should use an MCP gateway or proxy to centralize and standardize OAuth flows, comprehensively log them, and integrate MCP server use with existing IdP (Identity Provider platforms) and other security infrastructure.
MCP Manager is a secure gateway for leaders who are driving AI adoption in their organization. It provides end-to-end logging and observability, policy enforcement, identity management, and more, allowing your organization to ensure speed of AI adoption while maintaining security.
Get started – speak to us about MCP Manager today.
