Topic 2: The model
18 min read·22 Sept 2026
A.1 When authorization applies
Authorization answers "is this caller allowed to do this?". In MCP it is defined only for HTTP transports. The 2026-07-28 specification says it plainly: implementations using an HTTP transport SHOULD follow the authorization spec, and implementations using stdio SHOULD NOT, and should instead take credentials from the environment.
The reason is who is on the other end. A stdio server is a child process started by the host, on the user's machine, with the user's permissions. There is no network in between, and there is no Authorization header on a pipe. The security boundary is the operating system process. An HTTP server, on the other hand, accepts connections from anyone who can reach it, so it has to ask every request who sent it.
| Situation | Use this | Why |
|---|---|---|
| Server runs locally as a subprocess of the host (stdio) | Credentials from environment variables, no OAuth | The launching user is the only caller; a pipe has no headers to carry a token |
| Server is reachable over the network (streamable HTTP) | OAuth 2.1 bearer tokens, as in this module | Every request could come from anyone; each must prove who it is and what it may do |
In-memory Client(server) in tests | Nothing, and test auth separately over HTTP | The in-memory client talks straight to the server object and skips the HTTP layer, auth included |
HTTP server bound to 127.0.0.1 for one developer | Still add auth before anyone else can reach it | Localhost is reachable by every process on the machine and, without Origin checks, by web pages (Module 2) |