Agentgateway now supports ID-JAG and MCP Enterprise Managed Auth

Authors: Christian Posta (solo.io), Sohail Pathan (Okta), Markus Kobler (solo.io)

The Model Context Protocol (MCP) gives agents a standard way to discover and connect to tools. But in the enterprise, that discovery cannot be a free-for-all. Organizations need to govern which users can access which MCP servers, which clients or agents can initiate those connections, and which external SaaS applications are approved. Visibility and control become harder when clients connect to MCP servers across an organization boundary (ie, a SaaS MCP server). Even when the connection is approved, asking each user to consent is the wrong model. Enterprise access to external applications should be centrally managed by administrators.

That is what the Enterprise Managed Authorization (EMA) extension for MCP enables. Built on the Identity Assertion Authorization Grant (ID-JAG) IETF OAuth draft, it lets enterprises automate the right token exchanges without per-user consent screens, while retaining control over access to MCP servers across identity domains, including SaaS applications like Asana, Figma, Linear, and Slack. In other words: ID-JAG gives MCP a standards-based way to move from user-managed consent sprawl to enterprise-managed authorization across SaaS boundaries.

How it Works

With MCP EMA / ID-JAG, the applications use the enterprise IdP for SSO to identify the user (SAML, OIDC, etc) and then when the application/AI agent wants to call out to an MCP server in a different identity domain/SaaS boundary, it exchanges its identity token for an "identity JWT authorization grant" which is just a fancy way to ask the enterprise "can I access this remote MCP server". From within the enterprise IdP, admin approval can be granted, scopes can be mapped, and the AI agent can get a token (ID-JAG) that can be used to exchange for an OAuth access token directly on the cross-boundary authorization server (ie, the SaaS's IdP). This approach uses token exchanges to eliminate any direct browser / consent flows.

Figure 1: MCP enterprise managed auth extension, aka, ID-JAG flow as implemented by an MCP client / AI agent

Some MCP clients will implement Enterprise Managed Authorization directly. We already see this direction with clients like Claude, Cursor, Docker, VS Code, and Zoom. But implementing this flow inside every enterprise agent, application, or internal tool quickly becomes expensive and fragile.

Onboarding Clients to ID-JAG

Clients and agents should not need to understand RFC 8693 token exchange, RFC 7523 assertion grants, ID tokens versus SAML assertions, scope intersection, error mapping, token caching, or revocation behavior. That is protocol machinery, not application logic. It belongs in the infrastructure layer. Recently, Sohail Pathan (Okta) contributed ID-JAG support to Agentgateway, an AAIF project. This means enterprises can use agentgateway to consistently and centrally apply policy/control with ID-JAG as well as onboard clients that know nothing about ID-JAG instead of forcing every client and agent to build it.

Figure 2: Offload ID-JAG implementation to agentgateway, clients continue using OIDC/SAML for SSO, all the token exchange requirements are taken care of by the gateway

For example, to configure agentgateway for crossAppAccess, we can specify in a backendAuth policy:

backendAuth:
  crossAppAccess:
    # Leg 1 — IdenX token endpoint (requesting-app client credentials).
    identityProvider:
      # `https://` host = HTTPS with TLS auto-configured (no :443 + backendTLS needed).
      host: https://idp.xaa.dev
      tokenEndpointPath: /token
      clientAuth:
        clientId: $XAA_CLIENT_ID
        method: clientSecretPost
        clientSecret: $XAA_IDP_SECRET
    # Leg 2 — resource authorization server (resource-client credentials).
    resourceAuthorizationServer:
      host: https://auth.resource.xaa.dev
      tokenEndpointPath: /token
      clientAuth:
        clientId: ${XAA_CLIENT_ID}-at-todo0
        method: clientSecretPost
        clientSecret: $XAA_RESOURCE_SECRET
    # The resource authorization server identifier; the ID-JAG is bound to it.
    audience: https://auth.resource.xaa.dev
    # RFC 8707 resource — the protected API (sent on the token-exchange leg).
    resources:
    - https://api.resource.xaa.dev
    scopes:
    - todos.read

Listing 1: Configuration for agentgateway to implement ID-JAG on a backend resource/MCP server

To see the full demo and working configuration using the https://xaa.dev identity provider, see the github.com/agentgateway/agentgateway/examples

See demo here: https://youtu.be/dPnR-NcbnDY

Standards Enable Interoperability

Demand is high for a solution for MCP enterprise managed auth, and the ID-JAG draft spec is being adopted by more and more identity and resource providers. On the identity-provider side, Okta has early-access support for Cross-App Access, where admins configure managed connections between requesting applications and resource applications, and Okta performs the ID-JAG token-exchange step on behalf of the enterprise.

"In an enterprise setting, asking a user to manually approve a connection to a SaaS tool is the wrong model. That's a decision that should be made by the IT admin, not the employee. It's no accident that we're seeing such rapid adoption of the Cross App Access spec. It gives us a standards-based way to make these connections secure, seamless, and scalable without compromising on admin control. It's great to see open standards being adopted in the supporting infrastructure for agents like agentgateway." - Aaron Parecki, Director of Identity Standards, Okta

Keycloak is also moving in this direction: its current work documents experimental receiver-side support for accepting an ID-JAG-style assertion and exchanging it for a local access token, while issuer-side support is still in progress.

Other IdPs and resource providers are in progress to support this spec such as Atlassian, Canva, Cloudflare, Cursor, Datadog, Docker, Figma, Glean, Granola, Keycard, Linear, MintMCP, Scalekit, Serval, Slack, Stytch by Twilio, Supabase, VS Code, WorkOS, Zoom, and Zuplo. This is exactly what we should expect from a standards-based pattern: not a single vendor, but an ecosystem of IdPs, clients, gateways, authorization servers, and SaaS applications gradually implementing interoperable pieces of the same flow.

MCP is becoming the common integration point for agents and tools, and enterprise authorization needs to converge there instead of fragmenting across one-off vendor implementations. The EMA extension gives the MCP community a shared model for enterprise-managed access, while the ID-JAG draft gives that model a standards-based OAuth foundation. With broad client, platform, identity, and SaaS support emerging around this pattern, enterprises can adopt MCP authorization as an interoperable architecture.