What Is an MCP Gateway, and What Does It Not Do for OAuth?

An MCP gateway is a proxy that sits between AI agents and the Model Context Protocol (MCP) servers they call. It gives agents one endpoint instead of many, filters which servers and tools each caller can reach, manages the credentials used for the servers behind it, and logs tool calls. It does not take over your MCP server’s token validation: when an MCP server uses the specification’s HTTP authorization, it must accept only access tokens issued for it, by an authorization server it trusts, and a gateway cannot make a token that was issued for something else valid at your server.

What is an MCP gateway?

MCP is the protocol that AI assistants and agents use to call tools. An MCP server exposes those tools (search a database, create a ticket, restart a service), and a client such as an editor or an agent connects to it. With a handful of servers this is manageable. With dozens of servers and many agents, a company wants a single place to decide who may call what and to see what was called, which is the job an MCP gateway does.

Typical gateway features are:

• one endpoint that fronts many MCP servers;
• allow and deny rules per user, agent or tool;
• storing and injecting credentials for the upstream servers, so the agent never holds them;
• an audit log of tool calls.

Which kinds of products are called MCP gateways?

The name covers several different designs, and vendors describe them in their own terms, so check each vendor’s current documentation for what a product does and what stage it is at. The designs fall roughly into three groups:

1. A hosted catalog and portal, where the gateway is a service that aggregates servers behind one URL and applies policy to the callers.
2. Network or device control, where the policy is enforced on the machine or network the agent runs from rather than at a central proxy.
3. A policy layer inside an identity product, where the gateway is part of a platform that already holds your users and applications, so it can tie tool access to who the agent acts for.

Identity vendors have started shipping gateways of this third kind. For one vendor’s design in more detail, see Okta Agent Gateway versus Keycloak for MCP authorization.

How is an MCP gateway different from an MCP server or an API gateway?

An MCP server exposes tools and does the actual work. An MCP gateway forwards and filters traffic to one or more MCP servers and does not do the tool work itself. An API gateway does a similar forwarding job for ordinary HTTP APIs, with features such as rate limiting and routing, and is not aware of MCP concepts such as tool names, tool arguments or the protocol version each request carries. Some products combine the two, which is part of why the terms blur.

A small team running a few servers can usually authorize each server directly; a gateway starts to pay off once you have many servers and agents, or customers who require their own controls.

What does a gateway not remove?

The MCP authorization specification (the 2026-07-28 revision, and every revision since 2025-06-18) says an MCP server must only accept tokens specifically intended for itself and must reject tokens that do not include it in the audience claim. The specification’s security guidance also forbids token passthrough, which means an MCP server must not accept a token that was issued for a different service and simply forward it.

That has a direct consequence for gateways. A gateway can decide who is allowed to reach your MCP server, but it cannot make a token valid for your server. The token your server receives still has to be issued by an authorization server your server trusts, for your server’s audience. If a gateway passed a token it had received for itself straight through to your server, it would be doing the passthrough the specification forbids, and your server would reject the token anyway because its audience names the gateway.

The same specification requires an MCP server to publish OAuth Protected Resource Metadata (RFC 9728) so clients can find its authorization server, and encourages Client ID Metadata Documents for client registration, as covered in Keycloak CIMD for MCP.

How should a gateway present tokens to your MCP server?

When the client sees the gateway’s own URL, it discovers the gateway’s metadata and asks for a token for the gateway, so that token is not valid at your server. There are three legitimate ways to handle this.

• Token exchange. The gateway exchanges the token it received (RFC 8693) at your authorization server for a new token issued for your server, so your server still sees a token with the right audience and a record of who it acts for.
• The gateway’s own credentials. The gateway authenticates to your server with its own client credentials, which is the “storing and injecting credentials” feature above. The user’s identity then has to be passed and audited separately, or your server loses track of who made each call.
• A transparent proxy. The gateway forwards requests without changing the URL the client sees, so the client requests a token for your server directly and the gateway only filters and logs.

If a vendor cannot tell you which of these its gateway uses, ask before a customer deploys it in front of your product.

What should an MCP server check before it sits behind a customer’s gateway?

If your product exposes an MCP server and customers might put a gateway in front of it, make sure of the following.

1. OAuth discovery metadata. Publish Protected Resource Metadata that points to your authorization server.
2. Client registration that works without a gateway. Support Client ID Metadata Documents where your authorization server allows, with pre-registered clients as a fallback.
3. Audience validation. Reject tokens whose aud does not name your server, and bind audiences using RFC 8707 resource indicators where your authorization server supports them. Where it does not, use client scopes with an Audience mapper, as described in why a Keycloak MCP server returns 401.
4. Scopes per tool or capability. A coarse “full access” scope makes every gateway rule less useful.
5. A machine-to-machine path. Agents that run without a user need a client credentials or token exchange route with its own, narrower permissions.
6. Your own audit events. A gateway log shows the calls it saw; your server should still record who did what, for incidents that bypass the gateway.

The decision tree for MCP authorization with Keycloak helps choose between these options, and securing MCP servers with Keycloak and OAuth 2.0 is the longer walk-through. Gateways are also a target in their own right, as the LiteLLM MCP auth bypass showed, and the current protocol direction is in the stateless MCP 2026-07-28 specification.

How does this map to Skycloak?

Skycloak provides identity management as a service on upstream Keycloak, which fills the authorization server role for your MCP server: it issues tokens, hosts login, and records login and admin events. Keycloak supports Client ID Metadata Documents as an experimental feature from 26.6 (behind the cimd feature flag), audience mappers on client scopes, and standard token exchange, with delegation (an act claim naming the agent) in preview from 26.8 as described in our token exchange and delegation post. Most of the checklist above is therefore realm configuration rather than custom code, while your own audit events are application code. Resource indicators are still experimental in Keycloak, so check the current feature status before you rely on them. Because the authorization server is standard OAuth, it is not tied to any one gateway vendor, though you should test the specific gateway your customer uses.

What should you do next?

If you run an MCP server, work through the checklist above before any customer puts a gateway in front of it, and write down which token pattern you support. If you are choosing a gateway, ask each vendor which of the three patterns it uses and how it preserves the identity of the person an agent acts for.

Frequently asked questions

Can an MCP gateway be my authorization server?

Yes, the specification allows the authorization server to be hosted with the resource server or to be a separate entity, and some gateways issue tokens themselves. Your MCP server must still validate that each token was issued for it, by an authorization server it trusts.

Can a gateway replace OAuth on my MCP server?

Not when you use the specification’s HTTP authorization. Your server has to validate audience-bound tokens whatever sits in front of it, and a gateway adds policy and visibility on top.

Does an MCP gateway need to support RFC 8707 resource indicators?

It needs to support whatever lets the token end up with the right audience for your server. Resource indicators are the standard way to ask for that, and where they are missing, audience mappers on client scopes are a workable substitute.

What should a gateway support to work with Keycloak?

It should forward or exchange the Authorization header, keep the WWW-Authenticate challenge and resource metadata on a 401 response so clients can discover the authorization server, and support RFC 8693 token exchange if it presents tokens on the user’s behalf.

Sources

• Model Context Protocol, Authorization specification, revision 2026-07-28, https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
• Model Context Protocol, Security Best Practices (token passthrough), https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices#token-passthrough
• IETF, RFC 9728, “OAuth 2.0 Protected Resource Metadata”, https://datatracker.ietf.org/doc/html/rfc9728
• IETF, RFC 8707, “Resource Indicators for OAuth 2.0”, https://datatracker.ietf.org/doc/html/rfc8707