What is the best MCP gateway for Okta in 2026?

Every Model Context Protocol (MCP) gateway worth shortlisting signs people in with Okta. The differences show up after sign-in. For an Okta shop, the best MCP gateway is the one that keeps Okta as the source of truth past the login screen: Okta groups decide which tools a person can call, Okta supplies the tokens for the services behind each server through Cross App Access, and deactivating someone in Okta ends their access everywhere. Few gateways do all three today, and the ones that don't are still the right choice for some teams.

This guide gives Okta shops five criteria they can test in a trial, then compares five gateways against them: Speakeasy, Cloudflare MCP Server Portals, Docker MCP Enterprise Gateway, IBM ContextForge, and Kong. It also covers Okta's own Agent Gateway, which belongs on some shortlists.

Isn't Okta SSO enough?

For a pilot, often yes. If one team uses three MCP servers, each with its own OAuth sign-in, putting Okta in front of the gateway handles authentication, and Okta's MFA and conditional access policies apply on the way in. Several gateways below read group membership from the Okta token at sign-in, which is current as of the moment the person authenticated and needs no extra integration.

The gaps appear as usage grows. SSO proves who someone is but says nothing about the second credential every MCP tool call needs: the token the gateway presents to Linear, Notion, or GitHub behind the server. In most gateways that token comes from a separate OAuth grant the person makes to each service, stored by the gateway and invisible to Okta. Those grants are why offboarding is harder than it looks. Deactivating a person in Okta stops their next sign-in, but a grant they made to an upstream service can outlive the Okta account unless something revokes it.

The MCP Enterprise-Managed Authorization extension exists to close that gap. Okta implements it as Cross App Access (XAA): after single sign-on, the client exchanges the person's ID token for an Identity Assertion JWT Authorization Grant (ID-JAG), then redeems the ID-JAG at the downstream service's authorization server for a short-lived, scoped access token. Okta checks that the person is assigned to the app and that a connection to that service exists before it issues anything, so Okta policy governs the upstream token as well as the sign-in.

What should an Okta shop test in an MCP gateway?

Five criteria separate the gateways below. Each one is something you can check in a trial with a test user and an Okta admin console open in another tab.

1. Okta SSO for the gateway. People and MCP clients authenticate through Okta, with Okta's MFA and conditional access in force. Every gateway here passes; check whether it uses OIDC, SAML, or both, because that decides what else works.
2. Group sync to tool-level access. Moving someone between Okta groups changes which tools they can call, at the level of individual tools rather than whole servers. Check whether membership arrives by SCIM push or as a claim in the sign-in token, because the two go stale in different ways.
3. Cross App Access support. The gateway obtains upstream tokens through Okta's ID-JAG exchange, so a person signs in once and reaches every service Okta has approved for them without a per-service OAuth prompt.
4. Upstream token handling. Where the token for the service behind each server comes from (a per-user grant, one shared credential, a token exchange, or Cross App Access), where it is stored, and who can revoke it.
5. Offboarding. Deactivate the test user in Okta and see what still works a minute later: gateway sessions, group-based roles, and stored upstream grants.

The second criterion hides a real trade-off. A groups claim in the token is current at sign-in and stale afterward until the person authenticates again, and Cloudflare's Okta docs note that Okta may omit memberships from a token that carries more than 100 groups. SCIM pushes changes as they happen, independent of sessions, but needs a provisioning app in Okta and a gateway that applies the events. Neither approach is wrong. You should know which one you're buying.

How do the five gateways compare on Okta?

Speakeasy: Okta stays the source of truth after sign-in

Speakeasy's MCP gateway is one part of the AI Control Plane, and its Okta support is built around the five criteria above rather than sign-in alone. The Okta IdP gateway use case walks through the product setup; this section maps it to the tests.

Sign-in and group sync. People sign in through single sign-on with Okta over SAML 2.0 or OIDC, so Okta's MFA, device trust, and conditional access apply, and the platform holds no separate password. Directory sync over SCIM provisions people and their group memberships before their first sign-in. Admins map an Okta group or an attribute value such as department_name to a role, and once sync is on, roles come only from those mappings: the role editor shows member rows as read-only, Managed by directory sync. SSO and directory sync are plan-gated, so confirm they are on your plan before a trial.

Tool-level access. A role grants mcp:connect, and the role editor narrows that grant to all servers, specific projects, specific servers, or specific tools. Remote and tunneled servers can be narrowed by tool name once their tool metadata is recorded. Each scope has a blocking counterpart, such as mcp:blocked_connect, that withdraws access even when another role grants it, and the same rules appear on each server's Team Access tab, where a rule can also exclude tools by annotation, for example blocking every destructive tool. The result is that adding someone to the Engineering group in Okta grants the tools mapped to Engineering, and removing them takes those tools away as soon as the change syncs. Roles can also be assigned to registered agent identities, which a directory doesn't sync.

Cross App Access. Enterprise Managed Auth implements the MCP Enterprise-Managed Authorization extension that Okta supports as XAA. A person signs in once with Okta and reaches every MCP server set up for them without an OAuth prompt per service. On each tool call, the platform exchanges the person's Okta ID token for an ID-JAG addressed to the downstream service, redeems it at that service's authorization server, and runs the call as that person. The Okta connection that powers setup uses three read-only scopes, okta.apps.read, okta.users.read, and okta.groups.read, to sync applications and check readiness. Speakeasy never writes to the Okta org, and that API service connection doesn't issue tokens or sign anyone in. Cross App Access itself is configured separately in Okta, by registering an AI agent, linking an OIDC app, and creating one resource connection per downstream service from a checklist in the dashboard.

Upstream tokens without Cross App Access. Services that don't support the ID-JAG grant keep the ordinary connect flow: a per-user OAuth token stored encrypted and refreshed by the platform, or one shared credential for the whole server, either a static key or a token the platform obtains with the OAuth client credentials grant. Sharing a remote server with a static credential has a walkthrough. A shared credential carries the app's permissions rather than the caller's, so narrow that server's Team Access to the people entitled to it.

Offboarding and audit. Removing, deleting, or suspending someone in Okta deprovisions them: membership and role assignments end right away, and agents they own are blocked until an admin reassigns them. For servers on Cross App Access, Okta refuses the next renewal or exchange, and the platform asks the person to sign in again rather than falling back to another credential. The org-wide Audit Logs feed records administrative activity with the actor, a diff, and the surface it came through, including MCP session revocations and identity chaining changes.

Which clients get in. Okta decides who may connect. Shadow AI, generally available under Guardrails for every organization, decides which AI tools may: enrolled devices report the coding harnesses and assistants they run, and a tool marked Blocked is refused when it authenticates, on every MCP server in the organization. Devices that aren't enrolled report nothing.

Where Speakeasy falls short for an Okta shop. Several limits are worth knowing before a trial:

• Okta-only, OIDC-only delegation. Enterprise Managed Auth supports Okta as its only identity provider, and SAML sign-in doesn't create a delegation. The Identity providers tab that hosts the Okta connection is in preview and enabled per organization.
• Downstream support decides coverage. Cross App Access only works for services whose authorization server accepts the ID-JAG grant. The rest keep a per-service connect step.
• Revocation isn't instantaneous. Downstream tokens already issued stay valid until they expire, and ending a session in the platform doesn't revoke anything in Okta or at the upstream provider.
• Managed only. Speakeasy runs as a managed gateway, and there is no edition you install in your own infrastructure.

That last point deserves more than a bullet for teams whose MCP servers sit on a private network. Speakeasy can serve hosted servers and gateways on a private route through a Tailscale tailnet, with each server set to public only, public and private, or private only, but Tailscale private access requires an Enterprise organization, and Tailscale is the only private network provider today. If your security policy requires the gateway's control plane to run in your own infrastructure, Speakeasy doesn't meet that requirement, and Docker, ContextForge, or Kong will. What is a private MCP gateway? separates the private-network requirement from the self-hosting one, which buyers often conflate. For servers behind your firewall that don't need a private client route, tunneled servers connect outbound from your network.

Cloudflare MCP Server Portals: strong SCIM, tools curated per portal

Cloudflare is the natural choice for a team already running Cloudflare Zero Trust. MCP server portals put multiple MCP servers behind one endpoint protected by Cloudflare Access, with tool curation, aliases, logs exportable through Logpush to a SIEM, and optional routing through Cloudflare Gateway for data loss prevention scanning on tool calls.

Cloudflare's Okta integration has the most complete SCIM handling of the other four gateways here. Okta signs people in over OIDC or SAML, and a separate SCIM app pushes users and groups. With Enable user deprovisioning on, removing someone from the SCIM app revokes their active Access sessions, and Group membership change reauthentication revokes sessions when someone's Okta groups change. One subtlety from the same page: Access evaluates group membership from the token at sign-in, and SCIM supplies the group names in the policy builder, so a group change takes effect at reauthentication.

Tool-level access is coarser. Admins choose which tools a portal exposes, and Access policies decide which users see each server, so giving two Okta groups different tool sets on the same server means building two portals. The portal doc also flags that a blocked user can still reach a server by its direct URL unless Access is configured as that server's OAuth provider, and that independent MFA isn't enforced for servers authorized through a portal.

Upstream, each server uses either per-user OAuth, where people authenticate to each server separately after signing in to the portal, or an admin credential shared by everyone who reaches it. The portal doc doesn't describe obtaining upstream tokens through Cross App Access. Okta lists Cloudflare among its XAA partners, and Cloudflare's Workers OAuth provider library accepts ID-JAGs for MCP servers built on Workers, which is the resource side of the flow rather than the portal fetching tokens on a person's behalf.

Docker MCP Enterprise Gateway: Okta groups become Docker teams

Docker's MCP Enterprise Gateway suits teams that want MCP governance in their own infrastructure: Docker runs it in your own cloud account or VPC, or as an air-gapped appliance with no outbound connection, and has announced a Docker-managed cloud option. Containerized servers run isolated, credentials are read from your secret store at call time, and structured audit events per tool call go to your SIEM. The MCP Gateway docs note that the gateway as part of Docker AI Governance is invite-only, so expect a sales conversation before a trial.

Okta connects through Docker's organization SSO and SCIM. Group mapping turns Okta groups named in an organization:team format, such as moby:backend, into Docker team membership, sent at sign-in over SAML or pushed through SCIM. Docker's MCP access policies are written in Cedar and scoped to teams, so a person's tool access follows their Okta groups. The public MCP policy reference is written for Docker Sandboxes and documents two behaviors worth testing: a rule on a bare tool name applies to every server exposing a tool with that name, and tool listings can include tools that policy denies at invocation.

For offboarding, the group mapping page says group mapping through SSO manages team membership but doesn't deprovision users, so enable SCIM with Deactivate Users in Okta. Docker's public docs don't describe Cross App Access support.

IBM ContextForge: open source, groups mapped at sign-in

ContextForge is IBM's open source gateway for MCP, agent-to-agent, and model traffic, and it fits a team that wants to run and modify the gateway itself. It supports Okta over OIDC alongside other providers, with local admin authentication preserved for break-glass access.

Okta groups reach access through an OKTA_GROUP_MAPPING setting that maps group names to ContextForge team IDs, applied when a person signs in. Teams own tools, prompts, and resources, and team-scoped RBAC gates actions such as tools.execute. Session tokens resolve team membership from the database, so a membership revoked there takes effect immediately.

The gap is provisioning. The SSO docs say the bulk path for directory users is one admin API call per user and that it is not SCIM synchronization, and deactivation is a separate PATCH setting is_active to false. An Okta shop will need its own automation to turn an Okta deactivation into a ContextForge one.

Upstream token handling is flexible. Per-user OAuth tokens are stored encrypted per gateway and user and refreshed automatically, and an opt-in RFC 8693 token exchange can swap the person's ContextForge token for a downstream one. The same design doc lists a known gap: the gateway doesn't check a token's audience or scopes before forwarding it. ContextForge doesn't document Okta Cross App Access.

Kong: Okta groups in the token drive per-tool ACLs

Kong is the default answer for an organization that already runs Kong for its APIs and wants MCP under the same platform. The AI MCP OAuth2 plugin, part of the AI Gateway Enterprise offering, makes Kong an OAuth resource server for MCP traffic with Okta as the authorization server, validating every request by introspection or JWKS.

Kong's Okta group handling is direct. The plugin maps the token's groups claim to Kong Consumer Groups, and the AI MCP Proxy plugin applies allow and deny ACLs per tool against those groups, writing every allowed and denied attempt to an audit log. Kong's secure internal MCP gateway cookbook walks through this with Okta and recommends rejecting requests whose token has no matching group, since allowing them would let an unmapped caller bypass the ACLs. Because the groups come from the token, a group change lands when the client next gets a token from Okta, and there is no SCIM component on the Kong side to push it sooner.

Upstream, Kong strips the client's token by default to prevent confused deputy attacks, and can forward claims as headers, pass the token through, or perform an RFC 8693 token exchange for a token from a different authorization server. Kong's docs don't describe Okta Cross App Access. Offboarding follows Okta: once Okta stops issuing and validating tokens for a person, introspection rejects them, though introspection responses are cached by default.

What about Okta's own Agent Gateway?

Okta now ships pieces of an MCP gateway itself, under Okta for AI Agents. AI agents register in an AI Agents directory with owners and credentials, and Okta's Agent Gateway aggregates tools from remote MCP servers behind one Okta-secured endpoint, injects downstream credentials, and records tool calls. Admins choose the AI agents allowed to call a gateway and the tools it exposes, up to 200 per gateway.

For an Okta shop that wants every policy in the Okta console and mostly connects registered agents to remote servers, that is a reasonable starting point, and it removes a vendor. Two things to check in a trial. Access is granted to registered AI agents, and each client is configured with the gateway URL and that agent's client credentials, so the unit of policy is the agent rather than the employee's group membership. And Okta labels the MCP server registration step a research release. The difference with Speakeasy is scope: Speakeasy uses Okta as the authority for people and upstream tokens, and adds server hosting, a catalog, distribution to teams, and guardrails around the gateway.

Which MCP gateway should an Okta shop choose?

Run the offboarding test from the criteria list against each finalist, because it exercises the other four at once. Then apply these rules:

• Choose Speakeasy if you want Okta groups to decide access down to individual tools through SCIM, upstream tokens to come from Okta through Cross App Access wherever the downstream service supports it, and a managed gateway is acceptable. If you need private network access, budget for an Enterprise organization.
• Choose Cloudflare MCP Server Portals if you already run Cloudflare Zero Trust and want SCIM-driven session revocation plus data loss prevention scanning on tool calls, and portal-level tool curation is fine-grained enough.
• Choose Docker MCP Enterprise Gateway if the gateway must run in your own VPC or air-gapped, and you can name Okta groups in Docker's organization:team format.
• Choose IBM ContextForge if you want an open source gateway you can run and change yourself, and you can build the provisioning automation it lacks.
• Choose Kong if Kong already fronts your APIs and you want per-tool ACLs driven by Okta groups on the same platform.
• Start with Okta Agent Gateway if your MCP traffic is mostly registered agents calling remote servers and you want everything in the Okta console.

If you're working through an Okta rollout for MCP and want to compare notes on Cross App Access, talk with our team. For the background on federated MCP sign-in, see MCP SSO, enterprise MCP authentication, and governing agent actions with enterprise identity.