Build1 publisher3 min readPublished
Sharing an MCP server across a team now costs an OAuth 2.1 authorization flow
The auth overhaul in the final MCP spec reaches only remote transports, which turns a compliance question into a question about deployment topology, and even the vendors credited with getting ahead of it need checking.
The Engineer · Build desk
What happened
- The MCP spec update dated 2026-07-28, final and current since late July, makes OAuth 2.1 mandatory for every remote MCP server.
- The requirement covers remote transports only, so servers speaking stdio to a process on the same machine never needed OAuth and still do not.
- GitHub's remote server is the only one of three early vendors that explicitly documents OAuth 2.1 with PKCE, and it does so per client across six editors including VS Code, JetBrains and Cursor.
- Stripe's hosted endpoint defaults to OAuth, but its documentation still references the pre-2026 authorization spec, so the roundup says to verify alignment before calling it compliant.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision A team that wants one shared server now decides between operating an OAuth 2.1 authorization flow and giving every engineer a private stdio install with its own credentials; under the final spec the hosted-server-on-a-static-token option in between is not compliant.
- cost The bill is not a server config flag. Swapping long-lived personal access tokens for short-lived refreshing credentials pushes work into every client that used to hold a static token, since the refresh happens there.
- exposure Nothing in the mandate governs what a tool executes once the caller is authenticated, so a server that passes the auth requirement can still pass a model's statement through to a schema drop.
- constraint Because vendor documentation can lag the spec it claims to meet, the compliance check falls per endpoint on whoever deploys it, and cannot be discharged by keeping a list of approved vendors.
Three of the four vendor servers in the dev.to roundup keep a local stdio path alongside the hosted endpoint [18], and the steering group's reference set of Filesystem, Fetch, Git, Memory, Sequential Thinking and Time is stdio-only, never talking to the network at all [3]. For most teams the spec does not compel an auth migration; it compels a choice between architectures.
That choice has a price on each side. Local servers need no auth setup, and nothing local is shareable across a team the way a hosted server is [4]. Sentry's own writeup, quoted in the roundup, says the local install workflow of cloning repos and managing config paths has "a lot of sharp edges" [12], which is a fair description of what you hand each engineer instead of standing up an authorization server. The hosted side buys sharing and owes a credential lifecycle: GitHub's remote server replaced long-lived personal access tokens with short-lived, auto-refreshing ones [7]. Refresh runs in the client, which is why the documentation is enumerated client by client rather than as a single server-side setting [6].
What the roundup does not supply is a size. There is no count or share of already-deployed remote servers that fail the final requirements [22], and the account of the spec itself here rests on one dev.to piece [21]. GitHub reached general availability in September 2025 [5], roughly ten months before the spec was finalised [19], which tells you where vendors were already heading and nothing about how many team deployments are behind. The blast radius has a known shape but no known size.
The more instructive failure in the roundup is older. Anthropic's reference Postgres server shipped a read-only mode meant to block writes, and it did not [14]. Datadog Security Labs documented the server accepting a semicolon-delimited COMMIT; DROP SCHEMA public CASCADE;, which broke straight out of the server's own read-only transaction [15]. The boundary was a transaction, so a statement that ends the transaction ends the boundary. A read-only mode you can leave with a semicolon is a policy statement, not a control that holds. The server had been archived in May 2025 in a bulk sweep of unmaintained reference servers, with the disclosure landing after that [16], and the roundup's advice for anyone running Postgres over MCP now is a maintained community fork with real query parsing and permission attenuation [17], on the grounds that a vendor's name does not guarantee its safety claims hold [24].
OAuth 2.1 settles which user is calling and says nothing about what the server will run for them, which makes those two separate budget lines [1]. A migration that ends at the token buys an identity for the audit log and leaves the tool layer as permissive as it was [15].
What to watch
- Whether Stripe's documentation moves off the pre-2026 authorization spec, which would settle the one compliance caveat the roundup raises.
- Whether Notion sunsets notion-mcp-server, removing the stdio fallback for teams that do not want a hosted OAuth flow.
- Whether maintained Postgres MCP forks enforce read-only through database grants and query parsing rather than a wrapping transaction.