Introduction
Model Context Protocol (MCP) connects AI agents to services that perform tasks. The protocol exposes resources much like a REST API. Protecting those resources requires a clear authentication and authorization layer. This post summarizes the current mechanisms, focusing on the 2025‑11‑25 specification while noting earlier versions.
Transport options
MCP supports two primary transports. The first runs the server as a local subprocess and communicates over standard input and output. The second uses HTTP streams and relies on OAuth 2.1 for security. A deprecated Server‑Sent Events transport is mentioned for completeness but should be avoided.
Local (stdio) transport
When the server runs as a child process, the client launches it directly. No network hop occurs, so the client and server share the same execution environment. Authentication is implicit; the client already controls the server process. Configuration, such as endpoint URLs or API keys, is supplied via environment variables. These variables also allow the server to authenticate downstream services, but the MCP specification does not prescribe a particular method.
Remote (streamable HTTP) transport
Remote servers operate over HTTP and must authenticate each request. The specification recommends OAuth 2.1 with the Authorization Code grant. Some public servers provide read‑only data and skip authentication, but those cases are rare. Most servers require a bearer token that proves the client’s identity and permitted actions.
Downstream authorization
The server often forwards requests to databases, APIs, or other services. The server should propagate the client’s identity when making those calls. Token exchange (RFC 8693) is a common pattern: the server presents the client’s token to an authorization server, receives a new token that includes both the client and server identities, and forwards that token downstream. The MCP specification forbids passing through tokens that were not issued for the MCP server.
OAuth 2.1 flow
The client begins with an unauthenticated request. The server responds with a 401 status and a WWW‑Authenticate header that points to a resource‑metadata document. That document lists one or more authorization servers trusted by the MCP server. The client retrieves the chosen server’s metadata, registers if necessary, and starts the Authorization Code flow.
PKCE with the S256 method is mandatory. The request includes a resource parameter that contains the MCP server URL. After user consent, the authorization server returns an authorization code. The client exchanges the code for an access token (and optionally a refresh token). The token is sent in the HTTP Authorization header as a Bearer value.
Token handling
Access tokens must be stored securely; they function like keys to protected resources. Tokens should never appear in URL query strings. Short‑lived tokens reduce risk if a token is exposed. When a token expires, the client can use a refresh token to obtain a new access token without repeating the user consent step. Some servers support scope reduction during a refresh request.
Future considerations
Current gaps include detailed guidance for server‑to‑server authentication and dynamic client registration support. Draft extensions propose a client‑credentials grant and an enterprise flow that bypasses the browser redirect. Rich Authorization Requests may provide finer‑grained scope control. The community continues to discuss these extensions on GitHub and in the MCP Auth interest group.
Conclusion
Securing MCP servers hinges on choosing the appropriate transport and implementing OAuth 2.1 correctly. Local servers rely on process isolation; remote servers depend on bearer tokens and well‑defined scopes. Developers should define clear scopes, enforce token validation, and consider token exchange for downstream calls. Participation in the MCP community helps shape upcoming specifications and ensures that authentication practices keep pace with evolving use cases.