Authorization server or gateway: where MCP auth belongs
Two patterns get called "MCP auth," and they are not the same thing. A plain-language guide to which one you actually need.
TL;DR
- An authorization server issues and signs tokens. A gateway sits in the request path and inspects traffic. They solve different problems.
- MCP auth does not require a gateway. The spec's model is a resource server validating tokens it was handed, with token issuance handled separately.
- A gateway adds an enforcement point and traffic visibility, at the cost of an extra hop and a component in your data path.
- Most production setups end up wanting both, because a gateway with no authorization server behind it is enforcing a decision nobody actually made.
"How do I add auth to my MCP server?" quietly contains two different questions, and mixing them up is the source of a lot of confusion when teams evaluate options. One question is about identity and consent: who is this agent, what is it allowed to do, and who granted that. The other is about traffic: what flows through my perimeter and where do I enforce policy on it. An authorization server answers the first. A gateway answers the second. This piece is about telling them apart and deciding what you need.
The gateway pattern
A gateway sits in front of your MCP server, on the request path. Every call passes through it, which is precisely what makes it useful. It gives you a single enforcement point, visibility into the traffic, policy at the edge, and rate limiting in one place. If you already run an API gateway for the rest of your services, routing MCP traffic through it is a natural instinct.
The cost is structural. A gateway is an extra hop on every call, which means added latency and a component that has to be highly available because it is now in the critical path. It also means your MCP traffic passes through something that has to be trusted to see it. None of this makes gateways wrong. They are a legitimate, widely used pattern. It does mean you are accepting a real trade in exchange for edge control.
Gateway pattern: every MCP call passes through the gateway, which enforces policy at the edge — at the cost of an extra hop and a component that sits in the data path and sees all traffic.
The authorization server pattern
An authorization server does not sit in the request path. It issues a signed token to the client through the OAuth flow, and then steps out of the way. Your MCP server validates that token locally against the authorization server's public keys (its JWKS), with no call back to the authorization server on each request. Only the OAuth flows themselves, the initial authorize and token exchange, actually touch the authorization server.
The practical effect is that there is no extra hop on your data path. The authorization server can be busy or briefly unavailable and your MCP server keeps validating tokens, because validation is a local cryptographic check, not a network round trip.
Authorization server pattern: the authorization server issues a signed token during the OAuth flow, then steps aside. MCP traffic goes straight from client to MCP server, which validates the token locally against the cached JWKS — no per-request hop through the authorization server.
The honest trade-off is revocation timing. Because validation is local and offline, a revoked token is not rejected instantly everywhere. It stays valid until it expires or until the next check against revocation state. That is exactly why token lifetime matters in this pattern: short-lived tokens keep the window small. Naming this trade openly is the difference between an accurate description and a sales pitch.
So which one do you actually need?
The honest answer is that they are usually not substitutes, and many production systems want both. A gateway does traffic policy. An authorization server does identity and consent. They sit at different layers and solve different problems.
The failure mode to avoid is running a gateway with nothing behind it. A gateway can enforce that a request carries a token. It cannot, on its own, decide who should have gotten that token, what scopes it should carry, or which user delegated the authority. Without an authorization server making those decisions, the gateway is enforcing a policy that was never actually defined. If you only stand up one of the two, an authorization server is the one that answers the questions auth is actually for.
Where AuthPlane sits
AuthPlane is an authorization server, not a gateway. It runs alongside your MCP server rather than in front of it. It issues and signs tokens, your server validates them locally against the JWKS, and your MCP traffic never passes through us. If you also want edge traffic policy, put a gateway in front and let it do that job while AuthPlane handles identity, consent, and token issuance behind it.
The bottom line
If you take one thing from this: "MCP auth" is two jobs, not one. Decide whether you need traffic enforcement, identity and consent, or both, and pick the component that matches each. You do not need a gateway to have real MCP auth, and you should not treat a gateway as a substitute for an authorization server. See how the alongside-not-in-front model works in practice: github.com/AuthPlane.
Sources
- MCP Authorization specification, 2025-11-25. https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
- RFC 9728, OAuth 2.0 Protected Resource Metadata (discovery and validation model). https://datatracker.ietf.org/doc/html/rfc9728