MCP gateways ranked / OAuth and credentials

MCP OAuth and credential handling at a gateway

A gateway earns its place by answering two questions on every tool call: who is this, and which credential should act for them. Here is how good gateways answer both, and what to ask before you buy.

Last reviewed

Two hops, two problems

Every call through a gateway has two legs, and each needs its own authentication:

  1. Client to gateway (inbound). The agent or client proves who it is acting for. This is where SSO belongs: the user signs in with your identity provider, and the gateway issues a token for itself.
  2. Gateway to tool (outbound). The gateway calls the MCP server or downstream API with a credential that service accepts: an OAuth token for that user, a short-lived credential, or a service secret.

Keeping the legs separate is the point. The client's token is for the gateway; the downstream token is for the downstream service. Neither should be passed through to the other.

How MCP authorization works

The MCP specification defines authorization for HTTP transports on top of OAuth 2.1. In the current revisions an MCP server acts as an OAuth resource server: it publishes Protected Resource Metadata (RFC 9728) that tells clients which authorization server to use, and clients request tokens bound to that specific server using resource indicators (RFC 8707). Local servers over stdio don't use this flow; they usually read credentials from their environment.

The specification's security guidance also forbids token passthrough: an MCP server must not accept tokens that weren't issued for it, and must not forward the client's token to downstream APIs. A gateway that simply relays the user's token to every tool breaks this rule.

Check it at the sourceThe authorization and security best-practice pages of the MCP specification at modelcontextprotocol.io/specification are the reference. Ask each vendor which revision their gateway implements.

A gateway sits in the middle of this in one of two ways:

  • As the authorization point for clients. The gateway exposes itself as an MCP server, runs the OAuth flow with clients (backed by your identity provider), and then makes its own, separate calls to downstream servers.
  • As an OAuth client to downstream servers. For each remote MCP server or API that needs OAuth, the gateway runs the consent flow once per user, stores the refresh token, and uses fresh access tokens on that user's calls.

SSO and SCIM

SSO (through SAML or OpenID Connect) lets people reach the gateway with the account they already have, under the same MFA and device rules. SCIM provisioning keeps users and groups in sync, so that removing someone from your identity provider removes their gateway access, and group membership can drive policy.

Without SCIM, offboarding depends on someone remembering to remove the user from the gateway too. Ask whether deprovisioning also revokes the downstream tokens the gateway holds for that user.

Per-user tokens versus shared service accounts

A gateway can call a downstream tool as the user (with that user's OAuth token) or as a service account shared by everyone.

  • Per-user tokens keep the downstream system's own permissions and audit log meaningful: an agent can only do what that person could do, and the tool's log shows who it was.
  • Shared service accounts are simpler but flatten everyone to one identity with the union of everyone's permissions. Use them only for read-only or low-risk tools, and only with tool-level policy at the gateway.
  • Just-in-time credentials go further: the gateway mints short-lived, narrowly scoped credentials for a single task, so there is no standing token to steal.

Secrets and API keys

Many MCP servers still take a static API key. A gateway should store these in a secrets manager (its own or yours, such as a cloud secrets service or Kubernetes secrets), inject them at call time, and keep them out of client configs, logs and traces. Ask how secrets are encrypted at rest, who can read them, and how rotation works.

Pitfalls to avoid

  • Token passthrough. Forwarding the client's token downstream breaks audience checks and turns the gateway into a confused deputy.
  • Shared consent. One admin connects an OAuth app, and every user's agent then acts with that admin's access.
  • Tokens in logs. Request logging that captures headers or tool arguments can leak credentials.
  • Over-broad scopes. Requesting every scope at connect time because it is easier than asking later.
  • No revocation path. Removing a user from the identity provider without revoking the refresh tokens the gateway holds.

What to ask vendors

  1. Which identity providers do you support for SSO, and do you support SCIM for users and groups?
  2. Is every tool call attributed to a specific person and agent? Show me the log entry.
  3. Which revision of the MCP authorization specification do you implement, for clients and for downstream servers?
  4. Do you ever pass a client's token through to a downstream service?
  5. Can downstream calls use per-user OAuth tokens? Who completes the consent flow, and where are refresh tokens stored?
  6. Do you issue short-lived or just-in-time credentials? What is their lifetime?
  7. Where are static secrets kept, how are they encrypted, and can we bring our own secrets manager?
  8. When a user is deprovisioned, what happens to their sessions and downstream tokens, and how fast?
  9. Can you prove tokens never appear in logs, traces or client config files?

The ranking scores every gateway on authentication and credential handling; Runlayer and Obot score highest on both.