iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
🧭

The New Standard for OAuth2: Why Cross App Access is the Future of Authorization

に公開
Security
OAuth 2
IETF
Okta
xaa
tech

Introduction — The Next Move to Eliminate "Unauthorized APIs" by Design

In my previous article "Passing Tokens but Not Tenants — Ending 'Unauthorized APIs' with OAuth 2.0 [Slack/Box Implementation]", I explained how to prevent API calls to unauthorized SaaS tenants like Slack or Box using implementation, proxies, and gateways. In short, it’s the idea of making it visible "to whom and where" a person or bot is connecting and blocking anything outside the allowlist.

A protocol-side solution to this challenge has emerged. Cross App Access (XAA), proposed by Okta, extends OAuth to bring app-to-app connections under the enterprise IdP's management. This enables secure token mediation that doesn't rely on user clicks (no-consent) and provides centralized visibility. Behind this are the IETF's progress on "Identity & Authorization Chaining" and its specific profile, "Identity Assertion Authorization Grant" (ID-JAG).

This information is based on the draft as of October 2025. Specifications may change in the future. Please check the latest drafts and official vendor documentation.

1. What is Okta / Cross App Access?

1.1 What is Okta?

Okta is an IdP that provides SSO (OIDC/SAML) and access control. In 2025, Okta announced Cross App Access, indicating a direction toward bringing visibility and control to "invisible OAuth" in agent and app-to-app integrations (currently in Early Access).

1.2 What is Cross App Access (XAA)?

  • The Substance (ID-JAG): An extension where an application uses ID assertions issued by an IdP (OIDC ID Tokens or SAML) as material to obtain a special IdP-signed JWT (ID-JAG), and then uses that to get an access token from another app's authorization server. In the response, it uses issued_token_type=urn:ietf:params:oauth:token-type:id-jag and the JWT typ is oauth-id-jag+jwt.
  • The Foundation (Identity Chaining): A combination of RFC 8693 (Token Exchange) and RFC 7523 (JWT Bearer Grant) defining patterns to carry over "who / what authority / what path" across domains.
  • Microsoft's Involvement: In the initial revision of the IETF WG version of Identity Chaining (-01, 2024-02-19), the affiliation of Arndt Schwenkschuster / Pieter Kasselman is clearly stated as Microsoft (affiliation notations changed in subsequent versions).

2. OAuth 2.0 vs XAA (ID-JAG) — Deepening Understanding by Comparing Flows

2.1 Conventional OAuth 2.0 (Auth Code + PKCE)

This is a common flow that always involves a user login and a consent screen.

While the IdP can track up to the SSO level, individual A→B connections often conclude within each app, making centralized visibility and revocation difficult—a key weakness.

2.2 XAA (ID-JAG) — The IdP Becomes the "Mediator"

The core idea is determining connection eligibility via IdP policy without additional user interaction.

Step 1: Token Exchange with IdP (Obtaining the "Letter of Introduction" = ID-JAG)

In this stage, A asks the IdP, "Please give me a letter of introduction (ID-JAG) to visit B."

POST https://idp.example.com/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange&
requested_token_type=urn:ietf:params:oauth:token-type:id-jag&
subject_token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...&
subject_token_type=urn:ietf:params:oauth:token-type:id_token&
resource=https://auth.b.example.com/
# + client authentication (client_secret / private_key_jwt)
Parameter Simple Meaning What does it show? / Why is it needed?
grant_type=...token-exchange "I want to exchange tokens" Tells the IdP that the call is being made in OAuth "exchange" mode.
requested_token_type=id-jag "I want an ID-JAG" Requests an ID-JAG (Letter of Introduction JWT) instead of a standard access token.
subject_token=<ID Token> "Proof of this person's identity" The "source material" showing whose context this is, as they have already logged in via OIDC.
subject_token_type=id_token Type of source material Declares that it is an ID Token (or the corresponding type for SAML).
resource=<B_AS's issuer> Destination of the letter Identifies the destination of the ID-JAG (B's Authorization Server). Enter B's issuer value. Note: audience MUST NOT be used in this profile.

✅ The IdP evaluates the policy and, if approved, returns a short-lived ID-JAG (JWT) to A (short-lived to ensure the latest policy is always reflected).

Step 2: JWT Bearer Grant to B_AS (Converting to an Access Token for B)

A presents the received ID-JAG to B's authorization server (B_AS) to have an access token for B issued.

POST https://auth.b.example.com/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&
assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6Im9hdXRoLWlkLWphZytqd3QifQ...
# + client authentication
Parameter Simple Meaning What does it show? / Why is it needed?
grant_type=...jwt-bearer "Bringing a JWT letter of introduction" Declares that token issuance is requested by presenting a JWT.
assertion=<ID-JAG JWT> The letter itself The ID-JAG issued by the IdP in Step 1. B_AS verifies the signature, iss, aud, etc.

✅ Upon successful verification, an access token usable for B's API is returned, and A can call B_API using Authorization: Bearer ....

2.3 Side-by-Side Comparison of Key Points

Aspect OAuth 2.0 XAA (ID-JAG)
Connection Arbiter Determined within each app's consent flow. Hard for the IdP to track. IdP arbitrates. Admins centrally allow/stop A→B connections.
User Operation Consent screen every time. Basically no-consent (automatic review based on admin policy).
Visibility Post-hoc tracking is difficult. Listed under "Managed connections" in the Admin Console; stopping it blocks new exchanges.
Standard Positioning RFC6749 / 7523 / 8693. Identity Chaining (WG) + ID-JAG (WG).
AI / Agents Redirect-based consent is unsuitable. Optimized for secure coordination between agents and apps.

3. Implementation Perspective: What the Resource Side / Requesting Side / Administrators Need to Do

3.1 Resource App (API Provider: B)

  • Configure SSO (OIDC/SAML) with the enterprise IdP.
  • Accept JWT Bearer Grant (RFC 7523) at the authorization server.
  • Verify ID-JAG using the IdP's JWKS (iss/aud/sub/client_id, etc.).
  • Consider short-lived tokens + sender-constraint (DPoP/mTLS) (security considerations for Identity Chaining).

3.2 Requesting App (Caller: A)

  • Establish user identity via OIDC → Obtain ID-JAG via the IdP's Token Exchange.
  • Present the ID-JAG to B's authorization server using JWT Bearer Grant to obtain an access token for B.
  • Renewal strategy: refresh_token is SHOULD NOT. Assume short-lived tokens and re-exchange.

3.3 Administrator (IdP)

  • Register/disable A (Requesting) ⇄ B (Resource) as a directional connection in "Manage Connections" of the Admin Console.
  • Logs/Auditing: ID-JAG issuance events are added to event types (app.oauth2.token.grant.id_jag).
  • Prerequisite: Both apps must support the "Connect with Okta" App Feature (requirement for establishing connections).

4. Summary

4.1 Summary

By centralizing the decision of "who touches what from which app" within IdP policies, XAA/ID-JAG advances both UX (no-consent) and governance simultaneously. It is worth understanding as a foundational element for the era of AI agents.

  • Identity & Authorization Chaining (IETF OAuth WG): The latest version is -06 (2025-09-12). It defines the combination of Token Exchange + JWT Bearer.
  • ID-JAG (IETF OAuth WG): Adopted by the WG as -00 (2025-09-08). It defines the id-jag type and the JWT typ=oauth-id-jag+jwt.
  • Microsoft's Involvement: In the initial version of Identity Chaining (-01), the author's affiliation was listed as Microsoft, indicating their involvement from the WG's design stage.
  • Product Status (Okta): Cross App Access is provided as Early Access. A "Manage Connections" tab has been added to the Admin Console.

4.3 Appendix: Very Brief Explanation of Terms

  • Identity Chaining: A pattern for exchanging tokens (RFC 8693) and passing them via JWT Bearer (RFC 7523) so that the context of "who/authority/path" is not lost even across multiple domains.
  • ID-JAG: A "letter of introduction" JWT signed by the IdP that contains identity and authority. It is issued with issued_token_type=id-jag and presented to an AS in another domain to be converted into an access token.

IETF / OAuth WG

Okta (Cross App Access, Documentation/Blog/Product)

Foundational Specifications (Reference)

Discussion