How the recent updates to the Model Context Protocol (MCP) introduce OAuth-based authorization, reshaping how enterprises can securely manage access to AI agents and tools.
The Model Context Protocol (MCP) is of great interest to IT decision makers because of the potential benefits it unlocks from within the existing resources of the enterprise. It is a critical piece that enables AI Bots or “agentic AI” to flourish.
The security aspects of MCP must be addressed before its widespread use can be planned (see my previous blog post to learn more). The latest revision of the MCP Base Protocol being developed openly by Anthropic PBC, now has an Authorization section that recommends the use of OAuth 2.1, and associated specs that handle discovery, metadata and token acquisition. This gives a good baseline to work with.
The adoption of OAuth 2.1 as well as some of the OAuth 2.0 specs by MCP is a clear indicator that identity-based authorization is the preferred security approach rather than any conventional network-based access technology. I’ll refer to that collection of OAuth specifications as just OAuth for the rest of this post.
The current model of use for MCP servers is that an individual configures MCP clients on their end-user device, which stores credentials to access each MCP server they want to use with their LLM. These stored credentials might themselves be long-lived OAuth tokens. A number of third-party or open-source MCP wrappers (which provide the MCP interface to services that do not support MCP) have been developed around popular SaaS services like Slack, JIRA, Salesforce, etc. Almost all of them require the client to store these credentials because the wrapper needs to call the downstream service’s APIs, and those typically accept the long-lived credential. It simply passes the stored credential from the client onto the target service.
The recent update to MCP (informally referred to as “3/26” because of the date the changes were released) incorporates OAuth as an optional way to authorize MCP requests.
With support for OAuth built into MCP, the current “stored credentials” approach is likely to give way to the MCP servers accepting OAuth code flow tokens instead of the current stored credentials approach.
With this, the model is likely to evolve to the following:
So in this model, the client doesn’t need to store access tokens forever. Instead, for each session, it requests the authorization server (AS) to provide an access token. The access token is used to access the specific functionality in the MCP server (which is the OAuth Resource Server).
In this process, the AS may consult policy and / or get user consent to authorize the issuance of the token. This is typically called the “OAuth dance” (there are variations of it for apps instead of browsers).
In the updated picture, the AS becomes a crucial component. It is now responsible for adjudicating requests, consulting policy and issuing tokens that can be interpreted by MCP servers as authorization to do their work.
In a typical consumer-facing OAuth system, the identity provider often is the authorization server as well. It asks the user to consent to issuing tokens for specific scopes (e.g., “Event booking app” wants to use your profile picture). In enterprise scenarios where the user is an employee, there may be policy decisions made in addition to user consent (e.g., You are not permitted to use “Event booking app”).
In both these cases, the consent or the policy decision (or both) are limited to a “scope” of use. (e.g., the “profile picture” above). The AS needs to know which scopes exist across all possible apps using it, and how to present each scope to the user in a meaningful way. So in the above example, the scope name might have been “profile_pic”, but the user interface shows “profile picture” in the user’s preferred language.
In a non-AI system, this number of scopes could be standardized and their presentations / policies could be limited. The policy decisions to permit or deny access were also simple. For example, only users from admin group may have permission to the “maintain” scope
A number of new factors come into play with MCP:
As stated above, the requirements on the OAuth Authorization Server (AS) are quite different with MCP than without MCP.
To address these requirements, SGNL proposes having an MCP Security Gateway that acts as a proxy to all MCP servers that an organization would like to expose or use, The MCP Security Gateway acts as an MCP server to the MCP client (users only see one MCP server as a result). The MCP Security Gateway acts as a separate MCP client to every MCP server that it protects.
This gateway architecture is well suited because the security gateway can:
This architecture looks as follows:
The flow in this architecture is as follows:
In the above flow:
When the MCP client requests a tool from the MCP Security Gateway, in most cases, the enterprise policy may either directly allow or deny such requests.
However, sometimes an enterprise policy may dictate that under certain circumstances, the user’s consent is required to approve specific usage of specific tools. In this case, the MCP Security Gateway will specify the scope that the client needs to obtain from the external AS. This request to the external AS might result in the user being asked consent from the user in order to issue the token.
The MCP Security Gateway can be deployed for various scenarios:
MCP unlocks powerful capabilities but for enterprises to use this technology, the security needs to be handled carefully. The MCP proxy architecture described here can help secure MCP for enterprise scale deployments.
Talk to SGNL to learn more about the SGNL MCP Security Gateway, and how it can be rapidly adopted in your organization.
Want more of the latest identity-first security topics and trends delivered to your inbox? Helpful and insightful content, no fluff.