PostHole
Compose Login
You are browsing eu.zone1 in read-only mode. Log in to participate.
rss-bridge 2026-01-21T15:00:00+00:00

Is that allowed? Authentication and authorization in Model Context Protocol

Learn how to protect MCP servers from unauthorized access and how authentication of MCP clients to MCP servers works.

January 21, 2026

Is that allowed? Authentication and authorization in Model Context Protocol

Learn how to protect MCP servers from unauthorized access and how authentication of MCP clients to MCP servers works.

  • Credit: Alexandra Francis*

Model Context Protocol (MCP), released in late 2024, is an emerging standard for communication between AI agents and services used to complete tasks.

By using MCP, you can expose functionality to a variety of agents, from desktop clients to autonomous LLM-based agents running on other systems. After configuration, agents take the prompts and determine which MCP servers and MCP features to use to accomplish the goal of the prompt.

Yeah, I find it a bit spooky too.

An MCP server is similar to a REST API: it offers standardized remote access to resources, data, and functionality.

In this article, you’ll learn about how to protect MCP servers from unauthorized access and how authentication of MCP clients to MCP servers works. Both users of MCP servers and those who build them will benefit from a deeper understanding of this authentication layer.

This article assumes you are familiar with the basics of MCP, otherwise you might want to review the MCP specification or this introductory article.

There have been a few versions of MCP, but the three that relevant to authorization are:

If you are building MCP servers, make sure you understand which version your clients support since that affects the capabilities you can offer. This article focuses on the 2025-11-25 specification, with occasional information about the more widely implemented 2025-06-18 version.

If you are reading this more than a few months into 2026, check the latest version of the specification and ensure you understand any changes.

Authentication and authorization’s current status

What is the current status of authentication and authorization in MCP? These occur at the transport layer. There are currently two supported transport technologies:

  • stdio
  • Streamable HTTP

Let’s take a look at each of these, and how authentication happens.

Standard Input/Output (stdio)

This transport runs the MCP server as a local process. These are also called “local” MCP servers. All communication takes place over standard input and standard output.

When you pipe a request to curl, you are usually implicitly authenticated. Similarly, with the stdio transport, no authentication between the MCP client and MCP server is required. The MCP server is started as a subprocess of the MCP client.

Environment variables configure the MCP server. For example, you can set an environment variable with the value of an endpoint URL to the server. The server then can use that environment variable at startup to connect to the correct service endpoint. Environment variables are perfect for configuration during the MCP server boot up process. While data can be passed, no explicit authentication takes place between the MCP client and the MCP server.

You can manage the authorization process of services behind the MCP server by providing environment variables. If the MCP server supports it, you can add an API key environment variable. The MCP server can use this variable to connect to backend services, which can limit functionality and data based on the API key. The specifics of this authorization process vary by MCP server.

Just like a curl request can be authenticated using basic auth, an API key, or an OAuth token, the request between the MCP server and the APIs or services it relies upon can be authenticated in the same way.

The exact mechanism for authentication and authorization for requests made by an MCP server is outside the scope of the MCP specification. But you darn well need one. We’ll talk more about this issue below.

We won't discuss the stdio transport again, since most of the authentication complexity occurs when you have a remote MCP server using the streamable HTTP transport. Let’s take a look at that transport next.

Streamable HTTP

This transport, introduced in the 2025-06-18 specification, uses the OAuth 2.1 protocol and other standards-based solutions to authenticate and authorize MCP clients. MCP servers that use this transport are called remote MCP servers, whether the MCP server lives on localhost, a private URL or a public URL.

However, you can have a remote MCP server that requires no authentication or authorization. An example of this is the context7 MCP servers. These are remote MCP servers, but because they surface documentation and are read-only, they don’t require any verification of the MCP client. Such MCP servers are in the minority, though.

Most MCP servers allow MCP clients to take action, and therefore need to know who the MCP client is and what it can do.

For such MCP servers, you use an OAuth flow. To use the OAuth terms:

  • the MCP client is an OAuth 2.1 client
  • the MCP server is an OAuth 2.1 resource server
  • there is an authorization server

The authorization server is responsible for authenticating the MCP client, getting end user consent for the actions it is going to take, and issuing a token to the client. The client then presents the token to the MCP server, which validates it to ensure the client is authenticated and authorized. Per the MCP specification, the authorization process is an optional recommendation, but remote servers are strongly recommended to implement it.

We’ll dig into this OAuth process a lot more below.

SSE

For completeness, SSE is another transport which supports remote servers. It was deprecated in the 2025-06-18 specification and should not be used. It was replaced by Streamable HTTP.

Authentication and authorization from the MCP server downstream

As mentioned above, no matter what kind of communication protocol you are using to communicate from the MCP client to the MCP server, the question of authentication and authorization from the MCP server remains.

Because this logic is organization specific, it is difficult to give general guidance. An MCP server that is accessing a database will have different authentication and authorization logic than one that is accessing a REST API.

Plan to leverage whatever authentication and authorization solution that protected the data, functionality, or service before you created an MCP server.

However, it is important to avoid treating the MCP server as a monolithic entity. The MCP server is acting on behalf of the MCP client, and that information should be part of any authorization or authentication decisions.

An MCP server fielding a request from an MCP client that an admin user is using should have different capabilities than one from a non-admin user, for example, and that information needs to filter down to the requests the MCP server is making.

How to implement this depends on the authentication and authorization schemes you implement. When using the Streamable HTTP transport, Token Exchange is a good standards-based choice if the resources behind the MCP server expect OAuth tokens.

[...]

Original source

Reply