MCP authorization
Also written MCP auth, OAuth for MCP
MCP authorization is how a Streamable HTTP server decides whether a caller may connect. The specification requires internet-facing servers to use OAuth 2.1, and servers commonly answer an unauthenticated request with HTTP 401 plus metadata pointing at their authorization server. Local stdio servers have no such requirement.
How does authorization work in MCP?
For remote servers, over HTTP, the same way it works for any other API. The client presents a bearer token in an Authorization header, and a server that does not accept it answers 401 or 403.
The specification made OAuth 2.1 the requirement for internet-facing servers in its November 2025 revision. A conforming server that rejects an anonymous caller is expected to point at its authorization server rather than simply refusing.
Do local servers need it?
No, and requiring it would be pointless. A stdio server is a subprocess the user launched on their own machine, so the operating system's own boundaries already decide who can run it.
Authorization becomes necessary the moment a server is reachable at a URL, because then anyone can send it a request.
How common is a guarded server in practice?
More common than an open one. Across 82 connection attempts against 53 endpoints between 20 July and 5 August 2026, auth_required was the single most frequent outcome at 40 attempts, ahead of the 29 that connected.
That is the ecosystem's best-practice tier behaving correctly, not a fault line. The servers guarding themselves tend to be the production ones with real data behind them.
Example
An unauthenticated request to a guarded server returns 401 with a WWW-Authenticate header naming the resource metadata URL, which is the discovery entry point for its OAuth configuration. Supply a valid scoped token on the same request and the identical handshake proceeds to tools/list normally, which is how we check auth-guarded servers when a maker gives us a token for one run.