【続編】ノーガードだったMCPサーバーに認証をつける（Bearer Token編） A sequel post covering how to retrofit Bearer Token authentication onto an MCP server that…

Model Context Protocol (MCP) servers have quickly become a common way to expose tools, data sources, and application logic to AI assistants, but many of them are deployed without any access controls. This follow-up post walks through retrofitting Bearer Token authentication onto an MCP server that previously ran "no guard," a change that matters because an unauthenticated server reachable over a network can be invoked by anyone who discovers its endpoint.

MCP, introduced by Anthropic and since adopted across a range of AI clients and developer tools, standardizes how large language models connect to external capabilities. A server advertises tools and resources, and a client such as an AI agent calls them on the user's behalf. When an MCP server runs locally over the stdio transport, the operating system's process boundary provides a natural layer of isolation. The risk profile changes significantly once the same server is exposed over a network transport, such as HTTP with Server-Sent Events or the newer Streamable HTTP transport, because the endpoint is then reachable by any client that can send requests to it.

The core problem the article addresses is that a server without authentication treats every incoming request as trusted. If that server can read files, query a database, call internal APIs, or trigger actions, an exposed and unprotected endpoint becomes an obvious avenue for misuse. Adding authentication is therefore presented as a prerequisite for moving an MCP server from a local experiment into anything resembling a production deployment.

Bearer Token authentication is the mechanism chosen here, and it is attractive largely because of its simplicity. The scheme, defined as part of the broader OAuth 2.0 framework in RFC 6750, works by having the client include a token in the HTTP Authorization header, formatted as "Authorization: Bearer <token>." The server extracts that token, compares it against an expected value or validates it, and rejects the request with an HTTP 401 Unauthorized response if the token is missing or incorrect. Because the check happens at the transport layer, it can be applied uniformly to every tool the server exposes without changing the individual tool implementations.

In practice, the approach described appears to involve inserting a middleware or request-handling layer that inspects incoming requests before they reach the MCP message handling. The token itself is typically stored as an environment variable or in a secrets manager rather than hardcoded, and the client is configured to send the matching value. This keeps credentials out of source control and makes rotation easier. The article's framing as a sequel suggests the earlier post established the unauthenticated baseline, and this installment layers security on top of that existing implementation rather than rebuilding it from scratch.

It is worth noting the limits of a static Bearer Token. A single shared token offers coarse, all-or-nothing access and no way to distinguish between callers, so revoking access for one client means rotating the token for all of them. It also provides no protection on its own against interception, which is why Bearer Tokens should always be transmitted over TLS. For scenarios that require per-user identity, scoped permissions, or expiring credentials, the MCP specification has been evolving toward a more complete authorization story built on OAuth 2.1, including support for authorization servers, token endpoints, and discovery metadata. A static token is best understood as a pragmatic first step that is substantially better than nothing, rather than a comprehensive solution.

The broader context is that MCP security has become an active area of discussion as the protocol spreads. Reports of misconfigured or overly permissive servers, prompt-injection risks, and the dangers of connecting untrusted servers to capable agents have pushed both the specification maintainers and the community to emphasize authentication, least-privilege tool design, and careful handling of secrets. Adjacent practices such as running servers behind API gateways, using reverse proxies for TLS termination, and applying network-level restrictions complement token-based checks.

For developers maintaining their own MCP servers, the takeaway is straightforward: any server exposed beyond a local machine should require authentication, and Bearer Tokens offer a low-friction way to close the most obvious gap while more granular authorization models mature.