MCP authorization
Also written MCP auth, MCP authentication
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
What is MCP authentication?
Authentication proves who the caller is. Authorization decides what that caller may do. The MCP specification only defines the second, and it hands the first to somebody else.
Under the spec, a protected MCP server is an OAuth resource server. The user signs in at an authorization server the MCP server points to, which issues a token, and the MCP server itself only checks the bearer token each request carries. It never sees a password. So "MCP authentication" in practice means whichever sign-in that authorization server runs, and what MCP standardises is how a client finds it.
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. A server whose tools reach a user's own accounts needs it the moment it is reachable at a URL, because then anyone can send it a request. A server wrapping public data often runs without it.
How common is a guarded server in practice?
About a quarter. Of 1,039 addresses drawn at random from the official MCP registry and called on 20 August 2026, 24% asked for credentials and 63% answered anonymously.
The servers people name first guard far more often. Of the 53 well-known endpoints we called between 20 July and 5 August 2026, 30 refused an anonymous call, and auth_required was the single most frequent outcome. Their tools reach real accounts, so they guard; most of the registry wraps public data and does not. Nothing in the specification obliges either group to do it. What 1,039 servers do about OAuth has both samples and why they differ.
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.