Test Cross App Access (XAA) Flow

Learn how to test the end-to-end XAA flow.

Cross App Access (XAA) is currently in Beta. By using this feature, you agree to the applicable Free Trial terms in Okta’s Master Subscription Agreement. To learn more about Auth0’s product release cycle, read Product Release Stages. To participate in this program, contact Auth0 Support or your Technical Account Manager.

To test the end-to-end XAA flow, you need to verify that your Auth0 tenant can accept the JWT-Bearer requests sent by the Requesting App. Auth0 handles that for you out of the box.

Before you can test the end-to-end XAA flow, make sure you:

• Update the Redirect URI field to the callback URL of your testing application that acts as your Requesting App in your Okta tenant, as explained in Register the Requesting App in Okta.
• Provide your Okta representative with the following information:
  • The issuer URL of your Auth0 tenant. Your Resource App is associated with the issuer URL in the Okta Integration Network (OIN), enabling Requesting Apps to refer to it when requesting ID-JAGs.
  • The Auth0 client_id that maps to each Requesting App in the OIN.

To get the issuer URL and the client ID within your Auth0 tenant, navigate to Applications, select your application, and select Settings:

Field	Instructions	Example
Issuer URL	Copy your Auth0 domain, prefix it with https://, and add a trailing slash.	https://tenant.region.auth0.com/ or if your customers are using a custom domain, https://custom-domain.com/.
client_id	Copy the application’s client ID.	ovBLQycaVq6I0Xyuhq84pwDVyJeXWLyx

​

Exchange the ID token for an ID-JAG

First, you need to log in to your Requesting App with your Okta test tenant. When you successfully log in and grant consent, Okta redirects the browser back to your Requesting App with an authorization code. Your Requesting App then securely exchanges the authorization code for an Okta access token and ID token.

To exchange the Okta ID token for an ID-JAG, the Requesting App makes a token exchange request to the /token endpoint of your Okta test tenant with the following parameters:

POST /oauth2/v1/token HTTP/1.1
Host: {{YOUR_TENANT}}.okta.com
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
&audience={{YOUR_AUTH0_TENANT_ISSUER_URL}}
&resource={{YOUR_AUTH0_TENANT_API_AUDIENCE}}
&subject_token={{OKTA_ID_TOKEN}}
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&client_id={{REQUESTING_APP_CLIENT_ID_IN_OKTA}}
&client_secret={{REQUESTING_APP_CLIENT_SECRET_IN_OKTA}}

Parameter	Description
grant_type	The grant type. Set to the token exchange grant type: urn:ietf:params:oauth:grant-type:token-exchange.
requested_token_type	The type of token the client wants to receive back from the authorization server. Set to the Identity Assertion Authorization Grant, or ID-JAG: urn:ietf:params:oauth:token-type:id-jag.
audience	The intended recipient of the final token. Set to your Auth0 tenant issuer URL, or your Resource App whose authorization server is located at that specific URL.
resource	Optional. The Resource App’s API that the client wants to access. When the authorization server issues the final access token, it includes this resource in the token’s aud claim, which the Resource App’s API will use for validation. If you don’t specify a resource parameter, the default audience you set for your tenant is used in the next request to get an access token. If you specify a resource that does not match a valid API audience in your Auth0 tenant, the token exchange request does not fail and you still receive an ID-JAG in return. However, the subsequent request to get an access token with the ID-JAG will be rejected by your Auth0 tenant.
subject_token	The token the client is exchanging. For XAA, the subject token is the “proof” or “assertion” of the user’s identity. Set to the Okta ID token that the IdP will use to verify the user’s identity.
subject_token_type	The type of token provided in the subject_token parameter. For XAA, it specifies that an ID token is being presented to the authorization server.
client_id	The client ID of the Requesting App within the enterprise IdP that is making the token exchange request.
client_secret	The client secret that that Requesting App uses to authenticate itself with the enterprise IdP.

XAA Beta does not support passing scopes to Okta’s /token endpoint. You can set the scopes in the next request to Auth0’s /token endpoint once the Requesting App receives the ID-JAG.

In a production environment, the Requesting App makes the token exchange request to the /token endpoint of your customer’s Okta tenant.

​

Send ID-JAG to Auth0’s /token endpoint

Once the Requesting App gets an ID-JAG, it sends an access token request to the /token endpoint of your Auth0 tenant:

POST https://{{YOUR_AUTH0_TENANT_DOMAIN}}/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id={{REQUESTING_APP_CLIENT_ID_IN_AUTH0}}
&client_secret={{REQUESTING_APP_CLIENT_SECRET_IN_AUTH0}}
&scope=scope1%20scope2%20
&assertion={{ID_JAG}}

Parameter	Description
grant_type	The grant type. It tells the Authorization Server to expect a JSON Web Token (JWT) as the primary credential in the request.
client_id	The client ID of the Requesting App within the Resource App Authorization Server making the API call.
client_secret	The client secret of the Requesting App within the Resource App Authorization Server making the API call.
scope	The set of permissions the Requesting App is requesting for the access token.
assertion	The ID-JAG or JSON Web Token (JWT) that acts as the bearer of the identity assertion.

After the Auth0 Authorization Server validates the ID-JAG to verify the user’s identity, it issues an access token to consume the target API audience of your Auth0 tenant. The access token also includes the scopes you requested that are allowed by RBAC and other policies set in your Auth0 tenant.

The Auth0 Authorization Server does not issue refresh tokens in response to ID-JAG token exchanges. As a result, the Requesting App needs to get a new ID-JAG from the enterprise IdP, and undergo the applicable access controls, to get a new access token via XAA.