Skip to main content
Use this scenario when your enterprise is standardized on Okta: users sign in through Okta, applications are registered as Okta apps, and — optionally — agents are registered as first-class identities through the Okta for AI Agents product. TrueFoundry validates Okta-issued tokens on the inbound side (an identity provider-backed agent identity) and drives the Okta token exchanges on the outbound side, so no agent or app author implements an exchange themselves.
Two status facts frame everything, because they are the most misunderstood:
  • Cross App Access (XAA) — Okta’s productization of ID-JAG — is Early Access as of mid-2026 (enablement is not self-service; GA targeted for FY27).
  • Okta for AI Agents is a separate, paid product (GA April 2026). It is not the same thing as XAA. The distinction between “the protocol” (XAA/ID-JAG, usable on base Okta) and “the governance layer” (the paid product) is the crux of this page.

​
The building blocks Okta gives you

​
Okta application vs. Okta AI agent

The patterns below lean on two different kinds of principal:
  • Okta application — an app registered in Okta as an OIDC/OAuth client and (for XAA) listed in the OIN. Base Workforce Identity functionality; in an XAA exchange it plays the requesting or resource role.
  • Okta AI agent — an autonomous agent registered as a first-class non-human identity in Universal Directory through the paid Okta for AI Agents product. Beyond a plain application it gets an owner, a managed lifecycle (onboard, certify, kill switch), optional secret vaulting, and the entitlement to perform agent-to-agent token exchange — the onward, per-hop ID-JAG minting that a multi-agent chain needs.

​
Which pattern applies

Match your call path against this table; each pattern is detailed below. “3P” means a third party outside your Okta trust.

​
Pattern 1 — Okta app → MCP server, via XAA

Canonical Cross App Access. The MCP Gateway mints an ID-JAG at Okta and redeems it at the MCP’s authorization server for a scoped access token.
  • Register the client application as an Okta OIDC app (the requesting app), so a signed-in user obtains an Okta ID token.
  • Register the MCP server as an Okta app fronted by a custom authorization server (the resource app) — the server that redeems the ID-JAG.
  • Establish the Cross App Access trust: in the Okta Admin Console, create a managed connection from the requesting app to the resource app. (XAA is Early Access — enablement goes through Okta support, and both apps must be OIN-listed.)
1

Configure the MCP server's Auth Data for Cross App Access

On the MCP server, set Auth Type = OAuth2, OAuth Provider = Okta, Grant Type = ID-JAG (XAA – Cross App Access), then fill Resource Token URL (the resource AS token endpoint where the ID-JAG is redeemed), Resource Client ID / Secret (the client the gateway authenticates the redemption with), and Issuer URI (the resource AS issuer — the ID-JAG audience).
TrueFoundry MCP server Auth Data form: Auth Type OAuth2, OAuth Provider Okta, Grant Type ID-JAG (XAA - Cross App Access), with Resource Token URL, Resource Client ID, Resource Client Secret, and Issuer URI fields

MCP server outbound Auth Data configured for Okta ID-JAG (Cross App Access)

2

Create a virtual account for the client application

Create a virtual account representing the client app and grant it MCP Server User on the target server. At runtime the client presents this alongside the user’s Okta ID token, and the gateway runs the exchange above.
TrueFoundry virtual account MCP Servers permission: slack-xaa with role MCP Server User

Virtual account representing the client app, granted MCP Server User on the target MCP server

​
Pattern 2 — third-party MCP whose authorization server trusts Okta

The cross-vendor case, and the reason the IdP and authorization server are separate roles: the AS that redeems the ID-JAG does not have to be run by Okta. It just has to trust Okta as an ID-JAG issuer — a small explicit configuration on the resource side (Okta’s issuer identifier, its JWKS to verify signatures, and the accepted audience). The resource domain then validates ID-JAGs locally and mints its own tokens under its own policy — it never imports your user database and keeps full control of scopes and revocation. Setup is identical to pattern 1 — the same ID-JAG Auth Data and client virtual account — except Resource Token URL and Issuer URI point at the third party’s authorization server instead of an Okta custom AS.

​
Pattern 3 — third-party MCP with no Okta trust: per-user OAuth

When the third party is not part of any XAA trust, the flow degrades to standard 3-legged OAuth, managed by the MCP Gateway per user — consent, token storage, refresh. On the MCP server set Auth Data → OAuth2, provider Custom, grant Authorization Code; each user authorizes their own account on first use (the gateway returns a 401 with an authorization URL). No Okta XAA setup is involved.
TrueFoundry MCP server Auth Data form: Auth Type OAuth2, OAuth Provider Custom, Grant Type Authorization Code, with Authorization URL, Token URL, Client ID, and Client Secret fields

MCP server outbound Auth Data for standard per-user OAuth (Authorization Code)

At this boundary you lose the propagated identity assertion, the admin-visible connection, and centralized revocation — end-to-end governance stops at the untrusted hop. The gateway’s own audit and access control still apply.

​
Pattern 4 — multi-agent chains: Okta AI agents and chained ID-JAG

The full agentic call path — app → agent → agent → MCP — built on Okta’s agent-to-agent token exchange. Each hop mints a fresh ID-JAG audienced to the next callee’s authorization server and nests the acting agent into the act chain. The first leg starts from the user’s ID token; onward legs are seeded by the previous hop’s access token — the paid AI Agents product extends the base ID-JAG rule (which forbids an access-token subject) to allow exactly this. It is a chain of exchanges, not one carried token.
1

Register each agent as an Okta AI agent

In the Okta Admin Console (Okta for AI Agents), add each agent to Universal Directory with a human owner. Each gets a first-class non-human identity backed by an OAuth client. (Requires the paid product.)
2

Give each agent a custom authorization server

Its issuer becomes the ID-JAG audience for calls to that agent. Agents can share one custom AS (distinct scopes) or use one each.
3

Register the MCP server as a resource

The terminal MCP server is a resource protected by its custom authorization server, which redeems the final ID-JAG.
4

Authorize the connections along the chain

Configure connections for each hop — client → Agent A, Agent A → Agent B, Agent B → MCP — so Okta may issue a fresh ID-JAG per hop.
5

Share credentials with TrueFoundry

Provide each agent’s client ID and signing key plus AS details, so the gateways can perform the exchanges on the chain’s behalf.
On each agent and on the MCP server, set Auth Data → OAuth2, Grant Type = ID-JAG (Okta AI Agent), filling Resource Token URL (the next callee’s AS token endpoint), Resource Client ID, Private Key (Okta AI agents authenticate with a key, not a shared secret), and Issuer URI (the callee’s AS issuer). The Agent Gateway then mints the fresh ID-JAG at each agent hop and the MCP Gateway performs the final one.
TrueFoundry Auth Data form: Auth Type OAuth2, OAuth Provider Custom, Grant Type ID-JAG (Okta AI Agent), with Resource Token URL, Resource Client ID, Private Key, and Issuer URI fields

Agent outbound Auth Data configured for ID-JAG (Okta AI Agent)

If the chain terminates at a third-party resource instead, Okta brokers a third-party access token for the last hop (“Resource server” connected-resource type) — register that terminal MCP server with OBO (Token Exchange) Auth Data instead of ID-JAG.

​
Pattern 5 — same-tenant app-to-app: OBO, without an actor chain

Within one Okta tenant, the gateway performs an RFC 8693 OBO exchange on a custom authorization server. The resulting token keeps the user as sub — but Okta’s OBO emits no act claim, so the resource learns who the user is but not which agents touched the request. On the MCP server set Auth Data → OAuth2, OAuth Provider = Okta, Grant Type = Token Exchange, with the custom AS Token URL, optional Client ID / Secret, and Audience. No Cross App Access managed connection is needed for OBO.
TrueFoundry MCP server Auth Data form: Auth Type OAuth2, Grant Type Token Exchange (on-behalf-of), with Token URL, Client ID, Client Secret, and Audience fields

MCP server outbound Auth Data configured for On-Behalf-Of (Token Exchange)

​
What the gateway adds on top of Okta

Base XAA describes a single requesting-app → resource-app relationship. The TrueFoundry gateways fill three gaps:
  • Multi-hop chaining. The gateway registers in the OIN with the “Both” role — resource app for the upstream hop, requesting app for the downstream hop — and mints a fresh, freshly-audienced ID-JAG per hop, stitching single grants into one governed path.
  • Uniform governance across hops. Each resource AS enforces only its hop; the gateway runs the same authorize → exchange → guard → record loop at every hop.
  • Abstraction. Apps and agents present the identity they already have; the gateway does XAA or OBO on their behalf. No app author writes a two-legged exchange — which matters at scale, when many agents talk to each other in a mesh.

​
Without the Okta for AI Agents product

Patterns 1–3 and 5 work on base Okta (plus API Access Management for custom authorization servers). What the paid product adds is the lifecycle layer (registry, discovery, vaulting, kill switch, certification) and the agent-to-agent exchange that pattern 4 needs. The most consequential gap on base Okta: OBO emits no act claim, so an app → app → MCP path has no cryptographic actor chain.
Front the resource with an authorization server that does support nested actor tokens — for example Keycloak — and let the gateway drive it. Keycloak trusts Okta as the IdP (issuer + JWKS + audience), redeems the assertion, and uses its standard token exchange (RFC 8693, GA since Keycloak 26.2) to mint downstream tokens carrying the user as sub and the acting agent in act, nesting per hop. You get Okta’s centralized brokering and a verifiable actor chain.
Keycloak’s standard token exchange is GA, but the full act/may_act delegation semantics are still behind feature flags in current releases. Validate nested-delegation behavior on your version before depending on it.
Note the overlap with TrueFoundry: agent registry, ownership, kill switch, and audit are things the TrueFoundry implementation provides regardless of Okta licensing. Choose Okta for AI Agents when you want the directory itself to be the system of record for agent identities and the per-hop act chain minted by Okta.

​
FAQ

No. The terminal target only needs to be an XAA-enabled resource app — OIN-listed, fronted by an AS that redeems the ID-JAG. You register as AI agents the autonomous actors you want as first-class identities. An MCP server is a resource app, not necessarily an AI agent.
Multiple apps and agents can share one custom AS (different clients, different scopes). The nuance: each Okta custom AS has a single configured audience, so genuinely different audiences require multiple custom authorization servers or the audience/resource parameter.
In Okta’s XAA, yes — Leg 1 is performed by Okta as the IdP, so the subject token is an Okta-issued ID token (or SAML assertion). Okta can be federated upstream to another IdP, but what is presented to Okta’s token endpoint is still the Okta-issued assertion.
Every hop that participates in the XAA chain needs the trust relationship — requesting side via OIN/SSO, resource side via an AS that trusts Okta. A plain third-party app with no Okta trust cannot participate; that hop degrades to per-user OAuth (pattern 3).