Now That MCP Is Stateless, Authorization Matters More Than Ever

In late July, the community behind the Model Context Protocol (MCP) published a new version of its specification. Among many changes and improvements, there was one that feels especially impactful — the protocol is now stateless. Previously, a client had to first initiate a session with the MCP server before it would call any other endpoints (like listing tools or calling a concrete tool). This is no longer the case.

 Comparison between stateful and stateless version of the protocol

This is a good change. It makes implementations much simpler. MCP client developers will no longer have to deal with "server uninitialized" errors. They won’t have to worry about keeping the session ID safe, persisting it, or refreshing a stale session. Now, the client just calls server endpoints that it actually needs (like calling a tool) with no additional round-trips.

Stateless Protocols’ Caveat

Changing the protocol to stateless introduces the usual caveat: now that there's no session, the server needs another way to correlate requests from the same user or client instance. Fortunately, the protocol already makes use of a well-established technology fit for this purpose — OAuth and access tokens. An access token carries all the necessary information that the server needs to keep state. This change means that MCP authorization becomes essential for servers that rely on state. It also places more responsibility on the underlying identity provider (IdP) to enable enforcing this authorization.

Advantages Of MCP Authorization

Many existing MCP servers already rely on the specification’s authorization features and those that do not will have to quickly catch up. While sessions could be viewed as enough for state management, using OAuth to secure server access gives developers much more power and options.

Integration with Identity Providers

OAuth allows MCP server providers to easily integrate with any identity provider in a standardized way. The MCP client needs an OAuth access token to connect to the server, but the server can rely on any identity provider to issue the token. MCP server providers can utilize internal identity sources, federate with an external provider, or even use MCP extensions like the Enterprise Managed Authentication (EMA) to offer an SSO-like experience for users connecting to numerous MCP servers.

Such an approach also allows the MCP client to externalize the way in which users authenticate and give consent to an agent. The process stays in the control of the OAuth authorization server and can be dynamically changed or updated with new authentication options.

Access Token as an Information Point

An OAuth access token is a powerful source of information. It carries (either directly, in the form of a JWT, or by reference through an opaque token) all the information that is necessary to properly authorize a request. What is important is that information is attested by an authorization server and tied to the token in a tamper-proof way. Any recipient of the token can fully trust that data. In the context of agents and MCP this is especially important, as the recipients of the token are numerous:

• A gateway that sits at the edge of the connection to the MCP server, which provides features like initial rate-limiting.

• An MCP gateway that can implement coarse-grained authorization and route the request to the correct server.

• The MCP server which authorizes whether the caller is authorized to make the tool call.

• An API gateway that sits in front of the APIs that a tool eventually calls.

• All the APIs and microservices that handle the request.

Tokens Are Tailored During Request Processing

An important trait of an access token, and another advantage over sessions, is that an access token can be exchanged for another. Any component that handles the request can use OAuth's standard for token exchange to get a short-lived, least-privilege, locked-down token. This allows limiting security breaches should a token leak at any point of the request handling. Attackers are not able to abuse an exchanged token that was trimmed down in privileges, as it is only usable for a very concrete operation.

MCP Authorization is a Good Replacement of the Session

Dropping stateful sessions from MCP was a good decision. Not only it simplifies implementations, but it also puts more emphasis on properly authorizing access to MCP with OAuth and access tokens. Organizations are not able to develop secure and well-behaved agents without proper authorization in place. An attacker might try to trick an agent into misbehaving (e.g., using prompt injection), but robust authorization will stop the agent in time. Using OAuth to secure agents becomes a critical part of agentic security.

If you want to learn more and see a working example of an MCP server secured with OAuth take a look at Curity's MCP example.