MCP authorization
Also written MCP auth
MCP authorization is how a Streamable HTTP server decides whether a caller may connect. The specification makes it optional: a server that adopts it over HTTP should follow the OAuth 2.1 profile the spec defines, and then answers an unauthenticated request with HTTP 401 plus metadata pointing at its authorization server. Stdio servers should take credentials from the environment instead.
Updated
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 2025-11-25 revision is more careful here than it is usually reported to be, and the difference decides what you have to build. It states that authorization is OPTIONAL for MCP implementations, and only then constrains the shape: an implementation using an HTTP-based transport SHOULD conform to the profile the spec defines, which is built on OAuth 2.1. That is a conditional requirement. The spec does not tell you to put a public server behind a login. It tells you what your login has to look like if you add one.
What is unconditional, once a server is protected, is discovery. A protected server MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728), and MUST offer at least one way for a client to find it: a resource_metadata parameter on the WWW-Authenticate header of its 401, or a well-known URI. A guarded server is expected to point at its authorization server rather than simply refusing.
Do local servers need it?
No, and the spec says so directly rather than leaving it to inference: an implementation using stdio SHOULD NOT follow the authorization specification, and should retrieve credentials from the environment instead. 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.
Whether a remote server needs authorization is left to its operator. In practice the answer is usually yes the moment it 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 worth reading against the paragraphs above. Nothing in the specification obliges any of those servers to guard themselves. The production tier of this ecosystem converged on authorization without being required to, which is that tier behaving sensibly rather than a fault line.
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.