Skip to main content

Cross app access (XAA)

Let your identity provider govern which users, and which apps acting on their behalf, reach which MCP servers, instead of running a separate OAuth consent flow for every connector.

Enterprise-managed auth for your MCPs

Cross app access is available for MintMCP enterprise organizations. If you're interested in enterprise-managed authorization for your MCP servers, email enterprise@mintmcp.com and we'll enable it and walk through the Okta setup with you.

The MCP ecosystem calls this Enterprise-Managed Authorization: the enterprise IdP, not each user's consent screen, decides which applications connect to which MCP servers on a user's behalf. The flow is specified as an MCP authorization extension built on the IETF Identity Assertion JWT Authorization Grant (ID-JAG), which Okta ships as Cross App Access (XAA). MintMCP implements it for the MCP servers behind your gateway: when a user calls a tool, MintMCP requests an ID-JAG from your Okta org for that user and exchanges it for an access token at the MCP server's authorization server, so access policy, user assignment, and revocation live in Okta.

Why use it​

With standard per-user OAuth, each user consents to each connector individually, and MintMCP stores a refresh token per user per connector. Cross app access replaces that with an IdP-governed token exchange:

  • No per-connector consent. Users sign in once through SSO, and tokens for XAA connectors mint automatically when they call a tool.
  • Central policy in Okta. Your Okta admin controls which users can reach which resources, with which scopes, through Okta's AI agent resource connections. Removing a delegation in Okta cuts off new token mints without touching MintMCP.
  • No stored refresh tokens. MintMCP mints tokens just in time and never holds a long-lived credential for the downstream service on the user's behalf.
  • Dual attribution. Every token identifies both the human user and MintMCP as the acting agent, so the downstream service's own logs show who did what through which agent.

Okta is the supported identity provider today.

How it works​

The ID-JAG is a short-lived signed JWT that your IdP issues and the MCP server's authorization server accepts in place of an interactive OAuth flow. In the Enterprise-Managed Authorization model the MCP client performs this exchange, and MintMCP acts as that client for the connectors behind your gateway.

When a user calls a tool on an XAA connector:

  1. MintMCP asks your Okta org (through MintMCP's SSO layer) for an ID-JAG naming the signed-in user, the target audience, and the requested scopes. Okta only issues the grant if the user and resource are covered by an active resource connection on the registered MintMCP agent.
  2. MintMCP exchanges the ID-JAG at the MCP server's token endpoint using the standard JWT bearer grant (urn:ietf:params:oauth:grant-type:jwt-bearer, RFC 7523) and receives a resource access token.
  3. MintMCP sends the tool call to the MCP server with that token as the bearer credential.

The ID-JAG carries the claims the downstream service needs to make its own decision: iss is your Okta org, sub is the human user, aud is the MCP server's authorization server, scope lists the granted scopes, and act identifies MintMCP as the agent acting on the user's behalf.

MintMCP obtains short-lived resource access tokens per user and connector as needed, reusing a token only until shortly before it expires and never for longer than two hours, so revoking a user in Okta stops new access within that window.

Prerequisites​

  • SSO is configured for your organization with an Okta connection. See Configure SSO and SCIM.
  • Your Okta org supports Cross App Access, and MintMCP is registered as an AI agent in Okta's AI agents directory. The MintMCP team provides the agent's signing public key during enablement.
  • The Okta AI agent has a resource connection for each MCP server you want to reach, specifying the audience and allowed scopes, and delegations that cover your users.
  • The MCP server's authorization server supports the ID-JAG grant (it advertises the urn:ietf:params:oauth:grant-type:jwt-bearer grant type, and typically the urn:ietf:params:oauth:grant-profile:id-jag profile) and trusts your Okta org as an issuer. For third-party SaaS, this usually means your workspace with that vendor is federated to the same Okta org.
  • Users have signed in to MintMCP through the Okta SSO connection since cross app access was enabled, because the exchange runs on the IdP session established at sign-in.

Configure a connector​

  1. Navigate to MCP store in the MCP gateway sidebar
  2. Click + Add an MCP to your registry and select Connect to an MCP by URL, or open an existing remote MCP server's connection settings
  3. Under the authorization method, select XAA / ID-JAG ("Authorize with a delegated ID-JAG exchange"). The connection type switches to per-user credentials, which XAA requires
  4. Fill in the XAA / ID-JAG section:
FieldRequiredDescription
AudienceYesThe MCP server's authorization server, as an http(s) URL. Must match the audience of an active resource connection on the Okta AI agent (for example https://mcp.example.com)
ScopeYesScopes to request. Must be allowed by the Okta resource connection; the same scopes are requested at the token exchange (for example read)
Resource token endpointYesThe token endpoint where MintMCP exchanges the ID-JAG for a resource access token (for example https://mcp.example.com/token)
ResourceNoResource indicator (RFC 8707) sent on the token exchange, if the endpoint supports it (for example https://mcp.example.com/mcp)
  1. Save the connection. The server's authentication card shows Configured once the broker is in place, and there is no per-user connect step: tokens mint automatically on first use

Security model​

What your IdP controls:

  • Which users can mint grants, through the agent's delegations and your Okta sign-on policies (MFA and conditional access apply at SSO sign-in)
  • Which resources and scopes the MintMCP agent can request, through resource connections
  • Revocation: deactivating a user or removing a delegation in Okta stops new token mints

What MintMCP does:

  • Mints tokens just in time per user, and never stores an IdP refresh token for XAA connectors
  • Never injects an expired token; tokens at or past expiry are treated as missing credentials and minted again
  • Logs each exchange with the organization, user, and broker, so token mints are auditable alongside tool calls
  • Surfaces exchange failures to the client as a connection error with the reason ("Could not obtain an access token via ID-JAG exchange: ...") instead of failing silently

XAA connectors require per-user credentials, so the caller must be a signed-in user. Agent identities cannot call XAA connectors today because there is no human subject for the IdP to name in the grant.

Troubleshooting​

SymptomLikely cause
Exchange fails with a missing-token error for one userThe user has not completed a fresh SSO sign-in through the Okta connection since cross app access was enabled
invalid_target or an audience error from the IdPThe Audience does not match an active resource connection on the Okta AI agent
invalid_grant: Invalid assertion from the MCP serverThe ID-JAG was issued, but the server does not trust your Okta org or cannot map the user; check that the workspace is federated to the same IdP