Auth belongs in the MCP server, not bolted on in front

There are two places to authenticate an MCP server: at the edge (a gateway, an access proxy, your tunnel provider’s identity layer) or inside the server itself. Edge auth is the reflex — it’s how we’ve secured web apps for a decade. For MCP tools, it’s the wrong default.

The portability problem

An MCP tool leads several lives. It runs on your laptop during development, on a home box or VM in production, maybe in a customer’s environment later — and it serves Claude desktop, claude.ai web, and mobile, each with its own ideas about connecting to custom connectors.

Edge auth couples your security posture to one deployment topology. Move the container and the protection stays behind, wired into the infrastructure you left. Every new environment means reimplementing the same policy in a different vendor’s dashboard — and every reimplementation is a chance to get it subtly wrong.

When OAuth lives in the server, the security posture is a property of the image. The same container authenticates the same way everywhere it runs. Your dev instance, flipped to production posture, is one environment variable away — not one infrastructure migration away.

The double-auth trap

The usual compromise is “both”: an access layer at the edge and something in the server. In practice the edge layer and the MCP OAuth flow fight each other — the client has to satisfy two identity systems that don’t know about each other, and the failure modes (redirect loops, half-authenticated sessions) are miserable to debug across three different Claude clients.

Picking one owner ends the fight. Let the tunnel or gateway do what it’s good at — TLS, hiding your origin, absorbing junk traffic — and let the server own identity. Transport below, auth above, one boss per layer.

Allowlist verified emails, and fail closed

“Sign in with Google” alone only proves the caller has a Google account — that’s authentication without authorization. The missing half is an allowlist: after the provider verifies the token, accept only accounts whose verified email appears on an explicit list. Verified matters — an attacker can register any string as an email on some identity provider; they can’t verify ownership of one they don’t control.

And make the whole thing fail closed. If the allowlist is missing or the credentials aren’t configured, the server should refuse to start — not start open “temporarily.” Nobody remembers the temporarily. A tool that can’t boot into an unprotected state is a whole category of 3 a.m. incident you’ll never have.

The test

Wherever your auth lives, it should survive this question: if I moved this tool to a different machine, tunnel, or cloud tomorrow, would it still be protected — by the same code, with no dashboard to reconfigure?

If the answer is no, your security posture belongs to your infrastructure provider. If the answer is yes, it belongs to the tool — which is to say, to you.