A Gateway Architecture for Enterprise MCP Authentication: Unifying Heterogeneous Auth, Identity Delegation, and the User / Non-User Persona Problem

The paper reports on a production deployment of a centralized MCP (Model Context Protocol) gateway architecture that resolves a governance crisis caused by rapid, uncoordinated adoption of MCP servers within large enterprises. The crisis arose because each team implemented authentication independently, leading to a fragmented landscape with no consistent authorization, no unified audit, and no clean offboarding. The paper makes four contributions grounded in production experience:

C1 — A two-axis authentication model for MCP servers (Section 3). The paper shows that the authentication needs of every enterprise MCP server factor cleanly into a persona axis (interactive user vs. automated non-user) crossed with a credential axis (no-auth, static/dynamic API key, authorization-code-with-PKCE over static/dynamic clients, client credentials, platform app-context), all served through one endpoint. The key insight is that the persona axis is a security boundary: "Authorization-code-with-PKCE is available to users (it requires interactive consent) but not to non-users; client credentials and app-context are available to non-users but never carry a user identity. This asymmetry is what prevents a headless automation from impersonating a human."

C2 — A gateway authentication layer with three SSO grants and three token-provisioning models (Section 4). The gateway authenticates callers via Authorization Code + PKCE (for user personas with a browser), Device Code (for user personas on input-constrained or remote machines), or ROPC (for non-user personas, restricted to machine identities and never used for interactive humans). It offers integrators a choice of token-provisioning models: Bring-Your-Own-Token (BYOT), Generate-Your-Own-Token (GYOT), or full delegated OAuth via RFC 8693 token exchange. The gateway authenticates; downstream servers verify the issued tokens using a shared SDK. The paper notes that "Offering BYOT, GYOT, and full OAuth side by side is what lets a single gateway serve clients ranging from fully SSO-native web apps to thin custom-SDK agents—without forcing any of them to re-implement the others' machinery."

C3 — Three generalized end-to-end identity flows (Section 5): User→OAuth2, Non-user→Service-Account, and the subtle User→Service-Account case, each composing client, gateway, and server with explicit token handling. In Flow 1 (User→OAuth2), the gateway does not hand the raw OAuth2 token back to the client; instead it stores the token internally and returns an opaque session handle. In Flow 2 (Non-user→Service-Account), the downstream API key is provisioned to the gateway ahead of time and the gateway attaches it when forwarding; no user identity is involved and the downstream secret never transits the client. In Flow 3 (User→Service-Account), a human user is present but the downstream system is accessed via a service account, provided the user is authorized to use that service account. The key insight is that "Flow 3 is where most naive designs fail. Letting a user trigger a service-account-backed tool without an explicit authorization check is the confused-deputy escalation in disguise. The gateway's user-has-SA-access check, performed before attaching the service-account credential, is the control that makes this flow safe."

C4 — A deployment and connector evolution report (Section 7): from a CDN/WAF/edge perimeter with per-vendor IP allowlisting to private MCP tunnels, plus the design of enterprise-wide web and desktop connectors shared across the workforce. The paper documents the evolution through four stages: Stage 0 (user flow only via OAuth), Stage 1 (need for automation, adding service-account credentials and the non-user persona), Stage 2 (heterogeneity bites, pushing all auth into the gateway), and Stage 3 (delegation via RFC 8693 token exchange to carry both user and agent identities).

The architecture is in production, fronting dozens of MCP servers across web, desktop, custom-SDK, and low-code clients. The paper also discusses authorization across caller types, distinguishing gateway authorization (coarse-grained, identity-level decisions) from downstream authorization (fine-grained, resource-level decisions), with the design rule: The gateway answers 'may this identity reach this tool?'; the downstream system answers 'may this identity touch this data?'

Key lessons learned include: The hard part was organizational, not cryptographic; The two-axis model is the reusable idea; Centralization pays for itself at offboarding and audit; and Tool search matters as much as auth. The paper concludes that the two-axis model and the gateway-issues/server-verifies split are directly transferable to any organization facing the same MCP governance crisis.

Improvement 1: Enforce persona-credential compatibility in AI agent authentication.

The improved AI system can reject any authentication attempt where a non-user (headless) agent requests a user-only grant (e.g., Authorization Code + PKCE) or where a user persona requests a non-user-only credential (e.g., client credentials). This prevents confused-deputy attacks and impersonation by automation, making the system secure by default rather than relying on developer discipline.

Improvement 2: Implement a centralized gateway with dual-layer authorization for all tool calls.

The improved AI system can act as a single authentication and coarse-grained authorization gateway for all MCP servers, answering “may this identity reach this tool?” before forwarding. Downstream systems retain fine-grained control (“may this identity touch this data?”). This gives enterprises unified audit logs, centralized offboarding (revoke one gateway token to kill all access), and consistent policy enforcement across dozens of tools without per-server auth reimplementation.

Improvement 3: Support three token-provisioning models simultaneously (BYOT, GYOT, delegated OAuth).

The improved AI system can serve heterogeneous clients—from SSO-native web apps (BYOT) to thin custom-SDK agents (GYOT) to full delegated OAuth via RFC 8693 token exchange—through one endpoint. This eliminates the need for each client type to re-implement others’ auth machinery, reducing integration friction and enabling gradual migration of legacy clients without breaking existing workflows.

Improvement 4: Implement the three generalized identity flows with explicit token handling.

The improved AI system can:

• Flow 1 (User→OAuth2): Store the user’s OAuth token internally and return an opaque session handle to the client, so raw tokens never leak to the browser or agent.

• Flow 2 (Non-user→Service-Account): Attach pre-provisioned downstream API keys at the gateway without ever exposing them to the client, ensuring secrets stay server-side.

• Flow 3 (User→Service-Account): Perform an explicit “user-has-SA-access” check before attaching the service-account credential, preventing the confused-deputy escalation where a user triggers a privileged tool without authorization.

Improvement 5: Add a persona-aware token exchange for delegation.

The improved AI system can carry both user and agent identities in a single delegated token (via RFC 8693), enabling downstream systems to enforce policies that distinguish “human acting on their own behalf” from “human delegating to an automated agent.” This supports audit trails that answer “who authorized this action and which agent executed it?”—critical for compliance in regulated industries.

Improvement 6: Provide a two-axis authentication configuration interface.

The improved AI system can expose a declarative configuration where each MCP server declares its persona (user vs. non-user) and credential type (no-auth, API key, PKCE, client credentials, app-context). The gateway automatically enforces the security boundary (e.g., PKCE only for interactive users; client credentials only for non-users), eliminating misconfiguration and making the security model auditable at a glance.

Improved AI system capabilities (summary):

• Secure by default: Prevents impersonation and confused-deputy attacks via persona-credential compatibility checks.

• Unified governance: Centralized auth, audit, and offboarding for all MCP servers, reducing organizational overhead.

• Flexible integration: Serves web, desktop, custom-SDK, and low-code clients with three token-provisioning models.

• Safe delegation: Supports human-triggered service-account actions only after explicit authorization checks.

• Full traceability: Tokens carry both user and agent identities, enabling fine-grained downstream authorization and compliance reporting.

• Production-ready: Proven in a deployment fronting dozens of MCP servers, with clear evolution stages for scaling from user-only to mixed automation workloads.