A detailed implementation guide walks through adding Cross App Access (XAA) to an existing OIDC-federated resource application. It covers how the Identity Assertion Authorization Grant (ID-JAG) works, how to validate and resolve users from ID-JAG claims (iss, sub, tenant, email), how to issue scoped access tokens without refresh tokens, how to update authorization server metadata, and a full walkthrough for configuring and testing the setup in Okta using xaa.dev. It also notes differences for SAML-federated customers.
Table of contents
How XAA in OIDC worksAnalyzing the ID-JAG claimsXAA implementation checklist for OIDC-federated applicationsMaking cross-application requests from your OIDC app securelyConfigure your XAA OIDC Resource app in OktaVerify your Okta XAA setup on xaa.devTakeaways for implementors who also have SAML appsLearn more about Cross App Access, OIDC, and OAuth 2.0Questions this post answers
How do I validate an ID-JAG token before trusting its signature to prevent forgery?
Always resolve the IdP connection from the unverified iss claim first, then verify the JWT signature against that specific connection's JWKS endpoint. Checking the signature before binding the issuer to a registered connection lets an attacker stand up their own IdP, sign a token, and present a sub claim belonging to an existing user, so issuer binding must happen first. Developers securing app-to-app OIDC flows track validation patterns like this on daily.dev.
Why shouldn't a resource authorization server issue a refresh token when using Cross App Access with ID-JAG?
Issuing a refresh token gives the client durable access that the identity provider cannot revoke. The ID-JAG itself replaces the refresh token: when the access token expires, the client resubmits the same ID-JAG to the token endpoint for a new access token, and only once the ID-JAG expires does the client return to the IdP for a fresh one. Teams designing OAuth token lifecycles compare these tradeoffs on daily.dev.
How do I uniquely identify a user from the iss and sub claims in an ID-JAG token?
The sub claim alone is not unique; resolve on iss plus sub together, since two different identity providers could issue overlapping subject identifiers. If the IdP is multi-tenant, add the tenant claim to the key (iss plus tenant plus sub), because two customers on the same multi-tenant IdP could otherwise collide. Engineers building multi-tenant identity resolution reference details like this on daily.dev.