MCP Authentication in Production: Token Exchange, User Impersonation, and the Pattern Nobody Is Talking About

In our last post, we open-sourced fastmcp-gateway and solved MCP’s context collapse problem—replacing 150+ tool schemas with 3 meta-tools for progressive discovery. That post ended with a “what’s next” section that mentioned access control.

This is that post. And it turned out to be a much harder problem than tool discovery.

Here’s the uncomfortable truth about MCP authentication: the spec tells you what to do, but not how to do it. Section 7.3 of the MCP authorization specification is clear—each MCP server acts as a separate Resource Server with its own audience. Clients must not forward tokens issued for one resource server to another. That’s the requirement.

Now go look at every MCP authentication guide on the internet. Auth0, Stytch, Permit.io, AWS—they all explain the spec requirement. They show you how OAuth 2.1 fits into MCP. They draw architecture diagrams with boxes and arrows. What none of them show is what happens when your MCP server needs to talk to a platform like Snowflake that requires its own OAuth token scoped to the individual user making the request. That’s the gap we’re filling today.

The pattern: two layers, where each belongs

Authorization in the Axon MCP platform lives in exactly two places. Coarse “can this user call this tool” lives at the identity provider—enforced by scopes and app assignments in Okta, Entra, or Google Workspace. Fine-grained “can this user see row X, column Y, record Z” lives in the system of record—Snowflake RLS, Dynamics 365 security roles, Tableau row-level filters, Google Workspace sharing rules. Nothing lives in between. Not in our MCP layer, not in a parallel relationship graph, not anywhere.

This is not an accident. It matches how Doyensec’s 2026 MCP security research and the draft MCP Enterprise-Managed Authorization profile both converge: the IdP is the policy-enforcement point for cross-app authorization; the system of record stays the authoritative place for its own data. An earlier version of this post described a three-layer architecture with a relationship- based access-control (ReBAC) tier in the middle. We removed that tier in April 2026—it was duplicating permissions the backing systems already enforce better. The resulting architecture is simpler, more defensible, and exactly what the MCP spec is converging toward.

fastmcp-gateway (our open-source progressive-discovery gateway for MCP) exposes a lifecycle-hook interface at the request boundary. Authentication, scope enforcement, and downstream token exchange compose there as independent, stackable layers — the exact method names and header contract live in the OSS source and are out of scope for this post. The shape we deploy on the Ultrathink Axon™ platform:

Each layer is independent. Layer 1 (OIDC validation with IdP-granted tool-scope enforcement) is the coarse tool-level authorization tier — the gateway validates the JWT and checks that the required scope for the called tool is present. Stage 3 (RFC 8693 token exchange) is only needed for platforms that support user impersonation; for org-wide app-key downstreams it is bypassed at deployment time. The upstream MCP server itself implements no auth logic — it consumes the exchanged downstream token from the gateway and OAuth-connects to the backing system as the user.

Mode is a deployment-config decision, not a runtime inference. Each tool is declared in its capability manifest as one of three modes: user-impersonation, service-account, or app-key. That declaration is static, versioned, and reviewable — security teams can audit it in a single pass. A user-impersonation tool fails closed if an invocation arrives without a valid exchanged user token; a service-account tool runs on the configured service account regardless of whether any user context came with the request; an app-key tool runs on the shared credential the backing system requires. The presence or absence of a user-identity payload on an individual request is not a mode switch — header presence is evidence the caller is carrying a user token, not permission for the server to pick an auth mode on the fly. The pattern we’re ruling out is the silent-fallback anti-pattern where stripping an identity header causes a user-mode tool to downgrade into a service-account call; an attacker who can strip headers should not also get to choose the auth mode that applies.

Decouple identity propagation from authentication

This is the MCP security pattern that emerged from our production deployments: decouple identity propagation from authentication. The gateway does the hard part — OIDC validation, JWKS caching, scope enforcement, RFC 8693 exchange — and hands the upstream MCP server a verified, downstream-audience-bound token. Upstream servers become thin execution layers: no auth library dependencies, no duplicated validation code, no inference about who the caller is from headers they could forge. The exact header contract and configuration conventions live in the private deployment documentation we share under customer security review, not in public marketing — the architectural principle is what matters here, not the specific wiring.

What implementing this actually takes

RFC 8693 is elegant on paper. Taking it from spec to production — with a real enterprise IdP, a real data warehouse, and a real security team signing off — has sharp edges. The specifics of those edges are what we share under customer security review, not in marketing copy. But the categories of work are worth describing, because if you’re sizing the effort they’re what you’ll budget for. These are the three that consistently surprise teams the first time through.

Why this is a platform, not a per-team rebuild

The whole pattern above — IdP audience binding, scope enforcement, RFC 8693 exchange per downstream, explicit per-tool mode gating, token caching to keep the exchange out of the hot path — is configuration-driven in the Ultrathink Axon™ platform. Adding support for a new downstream data system in a customer deployment is a capability-catalog entry and a configuration bundle, not an engineering project. The upstream MCP servers stay thin; the identity-handling work that would otherwise live in every server lives in the platform layer exactly once.

That’s the practical reason this pattern — as opposed to the pattern most teams end up with on their first attempt (shared API keys in Kubernetes Secrets, bespoke middleware copy-pasted across four MCP servers, identity inference from whichever header happens to be populated) — is sustainable at enterprise scale. A company building AI agents against ten downstream systems does not want ten different token-exchange implementations, ten different mode-gating decisions, ten different fallback behaviors to audit. It wants one platform that gets this right once, and ten thin adapters sitting on top.

Token caching is the one implementation detail worth calling out because it’s the difference between “token exchange is a great pattern” and “token exchange adds 100ms to every agent tool call.” Exchanged tokens cache by the tuple of user identity and downstream platform, with TTL bounded by the IdP-issued token’s exp claim. For a user making ten queries against the same warehouse in a session, only the first triggers an IdP round-trip; the other nine reuse the cached downstream token. Per-request auth overhead amortizes to near-zero after the first call.

Worth being precise about invalidation because it’s often overclaimed in vendor marketing: cache invalidation is expiry-driven. A cached exchanged token remains valid until it expires — grant changes made at the IdP (a user losing a group membership, a scope being revoked, a role reassignment) do not retroactively invalidate already-cached tokens. The operational control is the TTL: short TTLs bound the staleness window (we default to minutes, not hours). Deployments that need tighter propagation layer on either push-based revocation from the IdP or periodic token introspection against the IdP’s revocation endpoint — both are industry-standard patterns, and both are on our roadmap beyond the short-TTL default. We call this out here because claiming “cache invalidates instantly on grant change” is a common security overclaim we want no part of.

Where the spec is heading: XAA and ID-JAG

Everything above describes the production pattern we shipped. But the standards world is catching up. The IETF’s Identity Assertion Authorization Grant (ID-JAG) draft (revision 01 at time of writing—check the datatracker for the latest) formalizes what we built—RFC 8693 exchange at the IDP—but adds an enterprise governance layer on top. The IDP doesn’t just issue tokens. It decides whether the exchange is allowed, based on app assignments and enterprise policy. The broader framework around this is called Cross-App Access (XAA).

The ID-JAG flow has two client-visible token endpoints and three parties: an identity provider, a resource authorization server, and a resource server. First, the client performs an RFC 8693 token exchange at the IdP — exactly what our platform’s exchange layer does today — producing an ID-JAG (Identity Assertion Authorization Grant). The IdP evaluates whether the requesting app is authorized to act on behalf of the user for the target resource and embeds that determination in the grant. Second, the client presents the ID-JAG to the resource authorization server’s token endpoint as an RFC 7523 JWT-bearer authorization grant; the resource authorization server validates the grant’s signature, issuer, audience, and policy scope and issues a resource-scoped access token that the client then uses to call the resource server itself. Two token endpoints, one continuous policy decision — and the IdP becomes the anchor point for “is this app allowed to act as this user against this resource at all?” rather than just a token issuer.

The MCP specification itself incorporated XAA as “Enterprise-Managed Authorization” in its November 2025 extension. Okta’s XAA Phase 1 is in Early Access (check Okta’s XAA page for current availability). No MCP client SDKs implement it yet. The spec is still early, but the direction is clear: enterprise identity providers will govern cross-application token exchange, and RFC 8693 is the mechanism underneath.

Track the spec at the IETF datatracker and explore the reference playground at xaa.dev.