diff --git a/main/config/navigation/secure.json b/main/config/navigation/secure.json index d22b06643f..b93fb8eb81 100644 --- a/main/config/navigation/secure.json +++ b/main/config/navigation/secure.json @@ -328,7 +328,8 @@ "group": "Cross App Access (XAA)", "pages": [ "docs/secure/call-apis-on-users-behalf/xaa", - "docs/secure/call-apis-on-users-behalf/xaa/set-up-xaa-test-environment", + "docs/secure/call-apis-on-users-behalf/xaa/set-up-requesting-app", + "docs/secure/call-apis-on-users-behalf/xaa/set-up-resource-app", "docs/secure/call-apis-on-users-behalf/xaa/manage-xaa-in-okta", "docs/secure/call-apis-on-users-behalf/xaa/test-xaa-flow" ] diff --git a/main/docs/secure/call-apis-on-users-behalf/xaa.mdx b/main/docs/secure/call-apis-on-users-behalf/xaa.mdx index 84b01bea9c..0eb2c251e8 100644 --- a/main/docs/secure/call-apis-on-users-behalf/xaa.mdx +++ b/main/docs/secure/call-apis-on-users-behalf/xaa.mdx @@ -19,9 +19,9 @@ This guide assumes you use Okta as your enterprise identity provider (IdP) and h -Connecting third-party apps and AI agents in an enterprise creates two key problems: poor IT visibility into data sharing and repetitive consent flows for users. +Connecting third-party apps and AI agents in an enterprise setting creates two key problems: poor IT visibility into data sharing and repetitive consent flows for users. -Cross App Access (XAA) addresses these challenges by allowing IT admins to centrally define access controls for how SaaS applications, like AI agents, connect on a user's behalf. Admins manage these connections in a central dashboard, like the Okta Admin Console, which eliminates disruptive OAuth consent prompts for end-users. The result is improved organizational security, governance, and user experience. +Cross App Access (XAA) allows IT admins to centrally define access controls for how SaaS applications, like AI agents, connect on a user's behalf. Admins manage these connections in a central dashboard, like the Okta Admin Console, which eliminates disruptive OAuth consent prompts for end-users. The result is improved organizational security, governance, and user experience. XAA implements the [Identity Assertion Authorization Grant](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/), an in-progress OAuth extension that allows an AI agent or application (Requesting App) to obtain a secure token through the enterprise IdP. This token enables the Requesting App to call the APIs of another application (Resource App) on the end-user’s behalf. To learn more, read [How it works](#how-it-works). diff --git a/main/docs/secure/call-apis-on-users-behalf/xaa/set-up-requesting-app.mdx b/main/docs/secure/call-apis-on-users-behalf/xaa/set-up-requesting-app.mdx new file mode 100644 index 0000000000..2718e9e959 --- /dev/null +++ b/main/docs/secure/call-apis-on-users-behalf/xaa/set-up-requesting-app.mdx @@ -0,0 +1,167 @@ +--- +description: Set up and register the Requesting App for Cross App Access (XAA). +sidebarTitle: Set up Requesting App +title: Set up Requesting App +--- + +import { ReleaseStageNotice } from "/snippets/ReleaseStageNotice.jsx" + + + + + +This guide assumes you use Okta as your enterprise identity provider (IdP) and have administrative access to an Okta tenant for testing. If you don't have one, read [Create and configure your Okta tenant](/docs/secure/call-apis-on-users-behalf/xaa/set-up-xaa-test-environment#create-and-configure-your-okta-tenant). + + + +This section explains how to set up the Requesting App for Cross App Access (XAA). The Requesting App and Resource App are connected using an OIDC connection pointing to the Resource App’s Auth0 tenant. The Requesting App uses the OIDC connection to make a token exchange request via the Token Vault to obtain an access token to call the API of the Resource App. For the Resource App setup, read [Set up Resource App](/docs/secure/call-apis-on-users-behalf/xaa/set-up-resource-app). + +To set up your Requesting App tenant, you need to: + +1. [Create the Requesting App in Auth0](#create-the-requesting-app-in-auth0): Create and register a confident client in Auth0 and enable XAA for it. +2. [Create the Okta Workforce Enterprise connection](#create-the-okta-workforce-enterprise-connection): Federate with Okta as the enterprise IdP so your users can sign in with their Okta credentials. +3. [Create the Resource App OIDC connection](#create-the-resource-app-oidc-connection): Create and register a connection that points to the Resource App's Auth0 tenant and enable Token Vault and XAA on it. + +## Prerequisites + +Before getting started, configure your Okta tenant for Cross App Access: + +- On the [Okta Developer website](https://developer.okta.com/signup/), sign up for an Okta Integrator Free Plan. +- In the Okta Admin Console, navigate to **Settings > Features**. Under **Early access features**, enable **Cross App Access**. + +![](/docs/images/xaa/okta_enable_xaa.png) + +You also need access to a Resource App Auth0 tenant. To set one up, read [Set Up Resource App](/docs/secure/call-apis-on-users-behalf/xaa/set-up-resource-app). From the Resource App tenant, you need: + +- The Resource App tenant's issuer URL. For example, `https://.auth0.com/` +- A Client ID and Client Secret for the Requesting App registered in the Resource App tenant + +## Create the Requesting App in Auth0 + +Create an application in your Requesting App Auth0 tenant representing the Requesting App. This must be a confidential client that can store a client secret, such as a Regular Web Application. + +In the Auth0 Dashboard: + +1. Navigate to **Applications > Applications** and select **Create Application**. +2. Enter a name (for example, `Agent0`) and select **Regular Web Application**. + +![](/docs/images/xaa/xaa_create_regular_web_app.png) + +3. Open the application's **Settings** and enable the **Cross App Access** toggle. + +![](/docs/images/xaa/allow_xaa_auth0_app.png) + +4. Navigate to **Advanced Settings > Grant Types** and enable the **Token Vault** grant type. This allows the application to use Token Vault to exchange tokens on the user's behalf. + +Note the application's Client ID; you will need it when registering the Requesting App in Okta. + +## Create the Okta Workforce Enterprise connection + +Create an Okta Workforce Enterprise connection in your Requesting App Auth0 tenant so your users can sign in using their Okta credentials. This connection also enables Auth0 to store Okta tokens in Token Vault during login. + +To [create an Okta Workforce Enterprise connection](/docs/authenticate/identity-providers/enterprise-identity-providers/okta), use the Okta application credentials for your Requesting App. + +Once the connection is created, configure it for XAA: + +1. Navigate to **Authentication > Enterprise > Okta Workforce** and select the connection. +2. Under **Settings > User Mapping**, select the **Okta Basic** template. +3. In the `userinfo_scope` property, add the `offline_access` scope so Token Vault can store a refresh token: + +```json +{ + "attributes": { + "name": "${context.tokenset.name}", + "email": "${context.tokenset.email}", + "username": "${context.tokenset.preferred_username}", + "federated_groups": "${context.userinfo.groups}", + "federated_locale": "${context.userinfo.locale}", + "federated_zoneinfo": "${context.userinfo.zoneinfo}" + }, + "mapping_mode": "use_map", + "userinfo_scope": "openid email profile groups offline_access" +} +``` + +4. Enable the **Cross App Access - Requesting Application** role for this connection using the Auth0 Dashboard or Management API: + + + + Under **Cross App Access Roles**, toggle on **Requesting Application**. This enables your Requesting App to request ID-JAGs issued by the enterprise IdP associated with this connection. + + + Make a `PATCH` request to the [`/connections/{YOUR_CONNECTION_ID}`](/docs/api/management/v2/connections/patch-connections-by-id) endpoint and set `cross_app_access_requesting_app` to `active: true`: + + ```bash + curl -L -X PATCH 'https:///api/v2/connections/' \ + -H 'Content-Type: application/json' \ + -H 'Authorization: Bearer ' \ + -d '{"cross_app_access_requesting_app": {"active": true}}' + ``` + + + +## Register the Requesting App in Okta + + + +In a production environment, the Requesting App developer registers the Requesting App in the Okta Integration Network (OIN). Enterprise customers install it from the OIN catalog during their IdP setup. + + + +The Requesting App must be registered in the Okta Integration Network (OIN) to be considered a valid XAA Requesting App. + +To register a new application in the OIN, read [Submission process for SSO and SCIM integrations](https://developer.okta.com/docs/guides/submit-app-overview/). Contact your Auth0 or Okta representative to accelerate this process. + +After adding the integration, configure the application's sign-on policy: + +1. In the Okta Admin Console, go to **Applications > Applications** and select the Requesting App. +2. Under **Sign On**, select **Edit** and add your Okta Workforce connection's **callback URL** in the **Redirect URI** field. +3. Select **Save**. + +Finally, assign your test user to the Requesting App: + +1. Select **Assignments > Assign > Assign to People** and select your test user. +2. Select **Save**. + +## Test the Okta Workforce connection + +In the Auth0 Dashboard: + +1. Navigate to **Authentication > Enterprise > Okta Workforce** and select the connection. +2. Select the **Applications** tab and enable the Requesting App you created. +3. Go back to the connections list, select the three dots next to your connection, and select **Try**. You will be redirected to authenticate with your Okta tenant. + +## Create the Resource App OIDC connection + +The Requesting App needs a connection in its Auth0 tenant that points to the Resource App's Auth0 tenant. This is how Token Vault knows which Resource App to target when exchanging tokens, and it is where you enable the XAA Resource App role on the Requesting App side. + +Use the Client ID and Client Secret that the Resource App tenant issued for your Requesting App to create an OIDC Enterprise connection in your Requesting App Auth0 tenant. + +To configure the connection for XAA: + +1. For **Purpose**, select **Connected Accounts for Token Vault**. +2. For the **OpenID Connect Discovery URL**, enter the discovery URL of the Resource App's Auth0 tenant: `https://.auth0.com/.well-known/openid-configuration`. +3. Enable the **Cross App Access - Resource Application** role using the Auth0 Dashboard or Management API: + + + + Toggle on **Enable Cross App Access Delegation**, then toggle on **Cross App Access - Resource Application**. This enables the connection to accept ID-JAGs targeting the Resource App's Auth0 tenant. + + + Make a `PATCH` request to the [`/connections/{YOUR_CONNECTION_ID}`](/docs/api/management/v2/connections/patch-connections-by-id) endpoint and set `connected_accounts` with `cross_app_access: true`: + + ```bash + curl -L -X PATCH 'https:///api/v2/connections/' \ + -H 'Content-Type: application/json' \ + -H 'Authorization: Bearer ' \ + -d '{"connected_accounts": {"active": true, "cross_app_access": true}}' + ``` + + + +Once the connection is created, you are ready to test the end-to-end XAA flow. To learn more, read [Test Cross App Access (XAA) Flow](/docs/secure/call-apis-on-users-behalf/xaa/test-xaa-flow). diff --git a/main/docs/secure/call-apis-on-users-behalf/xaa/set-up-xaa-test-environment.mdx b/main/docs/secure/call-apis-on-users-behalf/xaa/set-up-resource-app.mdx similarity index 93% rename from main/docs/secure/call-apis-on-users-behalf/xaa/set-up-xaa-test-environment.mdx rename to main/docs/secure/call-apis-on-users-behalf/xaa/set-up-resource-app.mdx index fd5e00b9b0..858b2270c6 100644 --- a/main/docs/secure/call-apis-on-users-behalf/xaa/set-up-xaa-test-environment.mdx +++ b/main/docs/secure/call-apis-on-users-behalf/xaa/set-up-resource-app.mdx @@ -1,7 +1,7 @@ --- -description: Learn how to set up the end-to-end test environment for the Resource App. -sidebarTitle: Set up XAA Test Environment -title: Set up Test Environment for Cross App Access (XAA) +description: Set up and register the Resource App for Cross App Access (XAA). +sidebarTitle: Set up Resource App +title: Set up the Resource App --- import { ReleaseStageNotice } from "/snippets/ReleaseStageNotice.jsx" @@ -13,15 +13,15 @@ import { ReleaseStageNotice } from "/snippets/ReleaseStageNotice.jsx" terms="true" /> -This section explains how to set up the end-to-end test environment for the Resource App. By configuring your Auth0 tenant as the Resource App Authorization Server, your SaaS application can start accepting incoming ID-JAG requests without requiring any code changes. This enables your SaaS API to generate access tokens in response to these requests, allowing AI agents and other applications to seamlessly consume your API. +This section explains how to set up the Resource App for Cross App Access (XAA). By configuring your Auth0 tenant as the Resource App Authorization Server, your SaaS application can start accepting incoming ID-JAG requests without requiring any code changes. This enables your SaaS API to generate access tokens in response to these requests, allowing AI agents and other applications to seamlessly consume your API. -This guide assumes you use Okta as your enterprise identity provider (IdP) and have administrative access to an Okta tenant you can use for testing. If you don’t have one, read [Create and configure your Okta tenant](#create-and-configure-your-okta-tenant). +This guide assumes you use Okta as your enterprise identity provider (IdP) and have administrative access to an Okta tenant for testing. If you don’t have one, read [Create and configure your Okta tenant](#create-and-configure-your-okta-tenant). -To set up your end-to-end test environment for the Resource App: +To set up the Resource App: - Configure and register your Resource App: This includes configuring your Auth0 tenant and registering your SaaS application as a Resource App with Okta. To learn more, read [Resource App setup](#resource-app-setup). - Configure the Requesting App to test the end-to-end: This includes registering a test Requesting App in your Auth0 tenant and updating Okta to link it with your Resource App. To learn more, read [Requesting App setup](#requesting-app-setup). diff --git a/main/docs/secure/call-apis-on-users-behalf/xaa/test-xaa-flow.mdx b/main/docs/secure/call-apis-on-users-behalf/xaa/test-xaa-flow.mdx index 8aae2b4031..2f6df68f5a 100644 --- a/main/docs/secure/call-apis-on-users-behalf/xaa/test-xaa-flow.mdx +++ b/main/docs/secure/call-apis-on-users-behalf/xaa/test-xaa-flow.mdx @@ -13,9 +13,12 @@ import { ReleaseStageNotice } from "/snippets/ReleaseStageNotice.jsx" terms="true" /> -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. +There are two ways to test the end-to-end XAA flow: -Before you can test the end-to-end XAA flow, make sure you: +- With Token Vault: Auth0 handles the full XAA flow on your behalf. Your Requesting App exchanges an Auth0 refresh token for a Resource App access token in a single request to Auth0. This is the recommended approach for production use. +- Without Token Vault (manual flow): Your Requesting App manages the XAA flow directly — exchanging an ID token for an ID-JAG at the enterprise IdP, then presenting that ID-JAG to the Resource App’s authorization server for an access token. + +Before testing, 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](/docs/secure/call-apis-on-users-behalf/xaa/set-up-xaa-test-environment#register-the-requesting-app-in-okta). - Provide your Okta representative with the following information: @@ -24,71 +27,126 @@ Before you can test the end-to-end XAA flow, make sure you: 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__ | +| __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` | +| `client_id` | Copy the application’s client ID. | `ovBLQycaVq6I0Xyuhq84pwDVyJeXWLyx` | +## Test with Token Vault -### Exchange the ID token for an ID-JAG +Token Vault lets your Requesting App exchange an Auth0 refresh token for a Resource App access token in a single call. Auth0 internally handles the ID-JAG exchange with the enterprise IdP on your behalf — your application never needs to interact with Okta’s `/token` endpoint directly. + +### Log in to the Requesting App + +Log in to your Requesting App through your Auth0 tenant using the Okta Workforce Enterprise connection. Include the `offline_access` scope in the authorization request to get a refresh token: + +``` +https:///authorize + ?client_id= + &scope=openid%20profile%20offline_access + &response_type=code + &redirect_uri= + &connection= +``` + +When the login completes, Auth0 returns an authorization code to your callback URL. Exchange it for tokens at the Auth0 `/token` endpoint. Auth0 returns an access token, ID token, and refresh token issued by your Auth0 tenant — the Okta tokens are stored internally in Token Vault. + +### Exchange the refresh token for a Resource App access token + +Make a token exchange request to your Auth0 tenant’s `/token` endpoint. Auth0 uses the refresh token to retrieve the ID token it stored during login, exchanges it for an ID-JAG at Okta, then uses that ID-JAG to obtain an access token from the Resource App’s authorization server. Auth0 returns the Resource App access token to your Requesting App and stores the refresh token in Token Vault for future requests. + +``` +POST https:///oauth/token +Content-Type: application/x-www-form-urlencoded + +grant_type=urn:auth0:params:oauth:grant-type:token-exchange:federated-connection-access-token +&requested_token_type=http://auth0.com/oauth/token-type/federated-connection-access-token +&subject_token= +&subject_token_type=urn:ietf:params:oauth:token-type:refresh_token +&audience= +&resource= +&client_id= +&client_secret= +``` + +| __Parameter__ | __Description__ | +|---------------|-----------------| +| `grant_type` | The Token Vault grant type: `urn:auth0:params:oauth:grant-type:token-exchange:federated-connection-access-token`. | +| `requested_token_type` | The type of token to receive back. Set to: `http://auth0.com/oauth/token-type/federated-connection-access-token`. | +| `subject_token` | The Auth0 refresh token obtained when the user logged in to the Requesting App. Auth0 uses this to retrieve the stored ID token and initiate the XAA flow with Okta. | +| `subject_token_type` | The type of token in `subject_token`. Set to `urn:ietf:params:oauth:token-type:refresh_token`. | +| `audience` | The issuer URL of the Resource App’s Auth0 tenant. For example: `https://.auth0.com/`. | +| `resource` | Optional. The API audience of the Resource App. When specified, the resulting access token’s `aud` claim will include this value. If omitted, the Resource App tenant’s default audience is used. If you specify a value that does not match a valid API audience in the Resource App’s Auth0 tenant, the request will be rejected. | +| `client_id` | The client ID of the Requesting App in your Auth0 tenant. | +| `client_secret` | The client secret of the Requesting App in your Auth0 tenant. | -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. +Auth0 returns the Resource App access token. Token Vault also stores the refresh token so that subsequent exchanges do not require the user to re-authorize. + +## Test the manual flow (without Token Vault) + +Use this approach to test the raw XAA protocol steps, or if you have not configured Token Vault. + +### Log in to the Requesting App + +Log in to your Requesting App through your Auth0 tenant using the Okta Workforce Enterprise connection. When the login completes, your Requesting App receives an Auth0 ID token representing the authenticated user. Auth0 obtains this by federating with Okta via the Workforce connection. + +### Exchange the ID token for an ID-JAG -To exchange the Okta ID token for an ID-JAG, the Requesting App makes a [token exchange request](https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html#name-token-exchange) to the `/token` endpoint of your Okta test tenant with the following parameters: +The Requesting App makes a [token exchange request](https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html#name-token-exchange) to the `/token` endpoint of your Okta test tenant to exchange the Okta ID token for an ID-JAG: ``` POST /oauth2/v1/token HTTP/1.1 -Host: {{YOUR_TENANT}}.okta.com +Host: .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}} +&audience= +&resource= +&subject_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}} +&client_id= +&client_secret= ``` | __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. | +| `grant_type` | The token exchange grant type: `urn:ietf:params:oauth:grant-type:token-exchange`. | +| `requested_token_type` | The type of token to receive back. Set to the ID-JAG type: `urn:ietf:params:oauth:token-type:id-jag`. | +| `audience` | The issuer URL of the Resource App’s Auth0 tenant. Okta uses this to identify which Resource App the ID-JAG is intended for. | +| `resource` | Optional. The Resource App’s API audience. Included in the ID-JAG’s `aud` claim, which the Resource App’s authorization server uses to validate the subsequent access token request. If you don’t specify a `resource` parameter, the Resource App tenant’s default audience is used. If you specify a value that does not match a valid API audience in the Resource App’s Auth0 tenant, the subsequent access token request will be rejected. | +| `subject_token` | The Okta ID token obtained when the user authenticated. Okta uses this to verify the user’s identity and apply XAA policy. | +| `subject_token_type` | The type of token in `subject_token`. Set to `urn:ietf:params:oauth:token-type:id_token`. | +| `client_id` | The client ID of the Requesting App registered in Okta. | +| `client_secret` | The client secret of the Requesting App registered in Okta. | -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. +XAA Beta does not support passing scopes to Okta’s `/token` endpoint. Set the required scopes in the next request to Auth0’s `/token` endpoint. -In a production environment, the Requesting App makes the token exchange request to the `/token` endpoint of your customer’s Okta tenant. +In a production environment, the Requesting App makes this request to the `/token` endpoint of your customer’s Okta tenant. -### Send ID-JAG to Auth0's /token endpoint +### Send the ID-JAG to Auth0’s /token endpoint -Once the Requesting App gets an ID-JAG, it sends an [access token request](https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html#name-access-token-request) to the `/token` endpoint of your Auth0 tenant: +Once the Requesting App receives an ID-JAG from Okta, it sends an [access token request](https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html#name-access-token-request) to the `/token` endpoint of the Resource App’s Auth0 tenant: ``` -POST https://{{YOUR_AUTH0_TENANT_DOMAIN}}/oauth/token +POST https:///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}} +&client_id= +&client_secret= +&scope=scope1%20scope2 +&assertion= ``` | __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. | +| `grant_type` | The JWT Bearer grant type: `urn:ietf:params:oauth:grant-type:jwt-bearer`. Tells the authorization server to expect a JWT as the primary credential. | +| `client_id` | The client ID of the Requesting App registered in the Resource App’s Auth0 tenant. | +| `client_secret` | The client secret of the Requesting App registered in the Resource App’s Auth0 tenant. | +| `scope` | The permissions the Requesting App is requesting for the access token. | +| `assertion` | The ID-JAG JWT returned by Okta in the previous step. | -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. +After the Resource App’s Auth0 Authorization Server validates the ID-JAG and verifies the user’s identity, it issues an access token scoped to the target API audience. The access token includes any scopes allowed by RBAC and other policies in the Resource App’s 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. +The Auth0 Authorization Server does not issue refresh tokens in response to ID-JAG token exchanges. The Requesting App must obtain a new ID-JAG from the enterprise IdP — and pass through the applicable XAA access controls — each time it needs a new access token.