The MCP spec that locks July 28 makes your server sellable to enterprises through Enterprise-Managed Authorization — an admin enables it once in their identity provider and every employee inherits access, no consent screens. But the spec is silent on one practical question: where does the ID-JAG token exchange actually run? You have two clean answers, and picking wrong means either code you didn't need or a proxy you didn't need.
The one-line decision, for anyone skimming: one server, in-server; two or more servers, a gateway. In-server means about thirty lines of JWT validation and zero new infrastructure. A gateway means a proxy that does the token exchange once for a whole fleet, keeps IdP secrets out of application code, and hands you caching, RBAC, and an audit trail for free — at the cost of a hop and a thing to operate.
When in-server is right#
If you ship a single MCP server, put the auth in the server. The validation is small — verify the ID-JAG's signature against a trusted IdP, check that its header typ is oauth-id-jag+jwt, that aud names your authorization server, and that the embedded client_id matches the client redeeming it. That's the whole gate, and we walked through it line by line in the ID-JAG tutorial.
The upside is bluntness: no extra network hop, nothing new to deploy, and the login lives next to the tools it protects. For a solo founder with one product surface, adding a proxy to do thirty lines of work is negative leverage.
When a gateway wins#
The calculus flips the moment there's a second server — or a second language, or a compliance team asking where identity is enforced. A gateway fronts every MCP server you run and does the token exchange once, so IdP wiring and secrets live in one place instead of being copied into each application.
The reference open-source option, agentgateway, opensourced gateway-side token exchange on 2026-07-12 under a single backendAuth.oauthTokenExchange block. It covers both grant shapes you'll meet in the wild: RFC 8693 for ID-JAG (Okta Cross App Access) and Microsoft Entra's On-Behalf-Of flow (jwt-bearer with requested_token_use=on_behalf_of). Same outcome — a user-scoped downstream token — normalized behind one config surface, so your servers never learn the difference.
Three things you'd otherwise hand-build come included:
- Token caching. The gateway reuses valid downstream tokens instead of running a fresh exchange on every tool call, so an agent loop doesn't hammer the IdP token endpoint — a real denial-of-wallet and rate-limit lever.
- Tool-level RBAC and per-user rate limits, enforced at the boundary rather than scattered through each server's handler code.
- A cryptographic audit trail at the choke point — which, for a regulated buyer, is often the thing that closes the deal.
Its v1.4.0-alpha.1 already targets the 2026-07-28 protocol version and Enterprise-Managed Authorization via Cross App Access, so you're not betting on vaporware.
The honest trade#
A gateway is a single identity choke point. That's a feature for auditing and trust rotation, and a liability for uptime — you now operate a proxy that everything routes through, and you patch it like the load-bearing infrastructure it is. In-server has no such single point, at the cost of duplicating auth logic every time you ship another server.
So don't over-architect on day one. Build the in-server version, ship your first enterprise deal, and graduate to a gateway when the second server forces the question. Because Enterprise-Managed Authorization is additive to plain OAuth 2.1, that migration doesn't change your server's contract — it still just receives an audience-bound bearer token. You move the exchange to the edge and delete some code. Start where the leverage is, and let fleet size, not fashion, decide when to move.
