diff --git a/main/config/navigation/secure.json b/main/config/navigation/secure.json index d22b06643f..dc6c0a4d80 100644 --- a/main/config/navigation/secure.json +++ b/main/config/navigation/secure.json @@ -329,7 +329,14 @@ "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/manage-xaa-in-okta", + { + "group": "XAA IdP Setup", + "pages": [ + "docs/secure/call-apis-on-users-behalf/xaa/idp/manage-xaa-in-okta", + "docs/secure/call-apis-on-users-behalf/xaa/idp/configure-okta-as-saml-idp", + "docs/secure/call-apis-on-users-behalf/xaa/idp/federate-with-enterprise-idp" + ] + }, "docs/secure/call-apis-on-users-behalf/xaa/test-xaa-flow" ] }, diff --git a/main/docs/images/xaa/xaa_auth0_connection_xaa_enabled.png b/main/docs/images/xaa/xaa_auth0_connection_xaa_enabled.png new file mode 100644 index 0000000000..3963d7372e Binary files /dev/null and b/main/docs/images/xaa/xaa_auth0_connection_xaa_enabled.png differ diff --git a/main/docs/images/xaa/xaa_auth0_new_okta_workforce_connection.png b/main/docs/images/xaa/xaa_auth0_new_okta_workforce_connection.png new file mode 100644 index 0000000000..7b9d72b46d Binary files /dev/null and b/main/docs/images/xaa/xaa_auth0_new_okta_workforce_connection.png differ diff --git a/main/docs/images/xaa/xaa_auth0_try_okta_connection.png b/main/docs/images/xaa/xaa_auth0_try_okta_connection.png new file mode 100644 index 0000000000..2744000946 Binary files /dev/null and b/main/docs/images/xaa/xaa_auth0_try_okta_connection.png differ diff --git a/main/docs/images/xaa/xaa_auth0_try_success.png b/main/docs/images/xaa/xaa_auth0_try_success.png new file mode 100644 index 0000000000..a7a2c84210 Binary files /dev/null and b/main/docs/images/xaa/xaa_auth0_try_success.png differ diff --git a/main/docs/images/xaa/xaa_okta_browse_req_app_in_oin.png b/main/docs/images/xaa/xaa_okta_browse_req_app_in_oin.png new file mode 100644 index 0000000000..a5a9721736 Binary files /dev/null and b/main/docs/images/xaa/xaa_okta_browse_req_app_in_oin.png differ diff --git a/main/docs/images/xaa/xaa_okta_browse_resource_app_in_oin.png b/main/docs/images/xaa/xaa_okta_browse_resource_app_in_oin.png new file mode 100644 index 0000000000..f2329798f5 Binary files /dev/null and b/main/docs/images/xaa/xaa_okta_browse_resource_app_in_oin.png differ diff --git a/main/docs/images/xaa/xaa_okta_login.png b/main/docs/images/xaa/xaa_okta_login.png new file mode 100644 index 0000000000..ffe5fe41c4 Binary files /dev/null and b/main/docs/images/xaa/xaa_okta_login.png differ diff --git a/main/docs/images/xaa/xaa_okta_req_app_install.png b/main/docs/images/xaa/xaa_okta_req_app_install.png new file mode 100644 index 0000000000..e24be8f96d Binary files /dev/null and b/main/docs/images/xaa/xaa_okta_req_app_install.png differ diff --git a/main/docs/images/xaa/xaa_okta_req_app_sign_on_policy.png b/main/docs/images/xaa/xaa_okta_req_app_sign_on_policy.png new file mode 100644 index 0000000000..7b3f52839e Binary files /dev/null and b/main/docs/images/xaa/xaa_okta_req_app_sign_on_policy.png differ diff --git a/main/docs/images/xaa/xaa_okta_req_app_user_assignment.png b/main/docs/images/xaa/xaa_okta_req_app_user_assignment.png new file mode 100644 index 0000000000..d655d1d311 Binary files /dev/null and b/main/docs/images/xaa/xaa_okta_req_app_user_assignment.png differ diff --git a/main/docs/images/xaa/xaa_okta_req_res_apps_connection.png b/main/docs/images/xaa/xaa_okta_req_res_apps_connection.png new file mode 100644 index 0000000000..99b222d4a8 Binary files /dev/null and b/main/docs/images/xaa/xaa_okta_req_res_apps_connection.png differ diff --git a/main/docs/images/xaa/xaa_okta_resource_app_details.png b/main/docs/images/xaa/xaa_okta_resource_app_details.png new file mode 100644 index 0000000000..84568af56c Binary files /dev/null and b/main/docs/images/xaa/xaa_okta_resource_app_details.png differ diff --git a/main/docs/images/xaa/xaa_okta_resource_app_install.png b/main/docs/images/xaa/xaa_okta_resource_app_install.png new file mode 100644 index 0000000000..c7eebfb370 Binary files /dev/null and b/main/docs/images/xaa/xaa_okta_resource_app_install.png differ diff --git a/main/docs/images/xaa/xaa_okta_resource_app_user_assignment.png b/main/docs/images/xaa/xaa_okta_resource_app_user_assignment.png new file mode 100644 index 0000000000..df3146deaf Binary files /dev/null and b/main/docs/images/xaa/xaa_okta_resource_app_user_assignment.png differ diff --git a/main/docs/images/xaa/xaa_req_app_details.png b/main/docs/images/xaa/xaa_req_app_details.png new file mode 100644 index 0000000000..f3bcc7f652 Binary files /dev/null and b/main/docs/images/xaa/xaa_req_app_details.png differ 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..a52ae0947f 100644 --- a/main/docs/secure/call-apis-on-users-behalf/xaa.mdx +++ b/main/docs/secure/call-apis-on-users-behalf/xaa.mdx @@ -15,7 +15,7 @@ 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 you can use 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 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](/docs/secure/call-apis-on-users-behalf/xaa/idp/manage-xaa-in-okta#create-and-configure-your-okta-tenant). @@ -58,6 +58,8 @@ In the following diagram, Acme is the enterprise customer whose employees authen - The Requesting App (Agent0) is registered with the Resource App Authorization Server as an OAuth 2.0 client with a valid client_id and credentials to request access tokens from the Resource App Authorization Server. - The Acme IT admin has defined XAA access controls between Agent0 and Todo0. +The Auth0 resource Authorization Server and the enterprise IdP are configured separately: see [Set up Auth0 XAA Environment](/docs/secure/call-apis-on-users-behalf/xaa/set-up-xaa-test-environment) for the Auth0 side, and [Configure Okta as OIDC IdP](/docs/secure/call-apis-on-users-behalf/xaa/idp/manage-xaa-in-okta) under **XAA IdP Setup** for the IdP side. + ## End-to-end XAA flow With our Acme example in mind, the end-to-end XAA flow has the following steps: @@ -71,6 +73,8 @@ With our Acme example in mind, the end-to-end XAA flow has the following steps: Leveraging the XAA flow, Acme’s IT admin policies govern access from Agent0 to Todo0, requiring no end-user redirection or interaction. +To set up this end-to-end flow, complete the Auth0 side via [Set up Auth0 XAA Environment](/docs/secure/call-apis-on-users-behalf/xaa/set-up-xaa-test-environment) and the IdP side via [Configure Okta as OIDC IdP](/docs/secure/call-apis-on-users-behalf/xaa/idp/manage-xaa-in-okta) under **XAA IdP Setup** in the sidebar. + ## Beta limitations XAA Beta has the following limitations: diff --git a/main/docs/secure/call-apis-on-users-behalf/xaa/idp/configure-okta-as-saml-idp.mdx b/main/docs/secure/call-apis-on-users-behalf/xaa/idp/configure-okta-as-saml-idp.mdx new file mode 100644 index 0000000000..b799f22010 --- /dev/null +++ b/main/docs/secure/call-apis-on-users-behalf/xaa/idp/configure-okta-as-saml-idp.mdx @@ -0,0 +1,7 @@ +--- +description: Configure Okta as a SAML identity provider for Cross App Access (XAA). Documentation coming soon. +sidebarTitle: "Configure Okta as SAML IdP" +title: "Configure Okta as SAML IdP" +--- + +Documentation for configuring Okta as a SAML IdP is coming soon. diff --git a/main/docs/secure/call-apis-on-users-behalf/xaa/idp/federate-with-enterprise-idp.mdx b/main/docs/secure/call-apis-on-users-behalf/xaa/idp/federate-with-enterprise-idp.mdx new file mode 100644 index 0000000000..06f87ecddf --- /dev/null +++ b/main/docs/secure/call-apis-on-users-behalf/xaa/idp/federate-with-enterprise-idp.mdx @@ -0,0 +1,30 @@ +--- +description: Add Organization support to a Cross App Access (XAA) IdP — federate your Auth0 tenant with the enterprise IdP and configure Organizations to associate access tokens with org_id. +sidebarTitle: "Add Organization Support to XAA IdP" +title: "Add Organization Support to XAA IdP" +--- + +import { ReleaseStageNotice } from "/snippets/ReleaseStageNotice.jsx" + + + + + +In a production environment, you configure each of your enterprise customers once to federate it with your Auth0 tenant. Auth0 will add support for [Self-Service SSO](/docs/authenticate/enterprise-connections/self-service-enterprise-configuration) in later versions, enabling you to delegate XAA configuration to your enterprise customers as part of SSO setup. + + + +## Configure an Organization + +Optionally, if you want an enterprise customer to use Organizations, [create an Organization](/docs/manage-users/organizations/configure-organizations/create-organizations) and [enable the Okta Workforce Enterprise connection](/docs/manage-users/organizations/configure-organizations/enable-connections) for that Organization. This automatically associates access tokens generated using XAA, in the scope of this connection, to the corresponding `org_id` if the target user is a member of the Organization. + +![](/docs/images/xaa/xaa_enable_connection.png) + +You can also configure the Requesting App’s [Organization behavior](/docs/manage-users/organizations/configure-organizations/define-organization-behavior) to set whether it is required or allowed to use Organizations. We recommend that you start testing with **Both**, which allows users to log in as an Organization member or sign up with a personal account. + +![](/docs/images/xaa/xaa_organizations_both.png) diff --git a/main/docs/secure/call-apis-on-users-behalf/xaa/idp/manage-xaa-in-okta.mdx b/main/docs/secure/call-apis-on-users-behalf/xaa/idp/manage-xaa-in-okta.mdx new file mode 100644 index 0000000000..01d9d4a874 --- /dev/null +++ b/main/docs/secure/call-apis-on-users-behalf/xaa/idp/manage-xaa-in-okta.mdx @@ -0,0 +1,149 @@ +--- +description: Learn how to configure Okta as an OIDC identity provider for Cross App Access (XAA). +sidebarTitle: "Configure Okta as OIDC IdP" +title: "Configure Okta as OIDC IdP" +--- + +import { ReleaseStageNotice } from "/snippets/ReleaseStageNotice.jsx" + + + +This page walks through configuring Okta as the OIDC enterprise identity provider for Cross App Access (XAA). You'll set up an Okta tenant, register the Resource and Requesting Apps in Okta, and configure a Workforce Enterprise connection so Auth0 can federate with Okta. + +## Create and configure your Okta tenant + +To set up your end-to-end test environment for the Resource App, you need to create and 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. Once you sign up, you should be redirected to your new Okta tenant. +- In the Okta Admin Console, navigate to **Settings > Features**. Under Early access features, enable **Cross App Access**. + +![](/docs/images/xaa/okta_enable_xaa.png) + +## Register the Requesting App in Okta + +### Create Requesting App in Okta + + +In a production environment, the Requesting App developer registers the Requesting App in the Okta Integration Network (OIN). Enterprise customers will install the Requesting App from the OIN catalog during their IdP setup. + + + +You must register the application in the Okta Integration Network (OIN) for it to be considered a valid XAA Requesting App when using Okta as the enterprise IdP. + +To register the Requesting App in Okta, you have two options: + +- For a quick test setup, we recommend using the **XAA Requesting App** that is already registered in the OIN. In the Okta Admin Console, go to **Applications > Applications > Browse App Catalog** and search for `XAA Requesting App`. Select it and add the integration. + +![](/docs/images/xaa/xaa_okta_browse_req_app_in_oin.png) + +- During XAA Requesting App install, configure **Issuer URL** to point to your Auth0 tenant and **Client ID** to point to your **Agent0** application in Auth0. + +![](/docs/images/xaa/xaa_okta_req_app_install.png) + +- You can also request the registration of a new application in the OIN. To learn more, read the [Submission process for SSO and SCIM integrations](https://developer.okta.com/docs/guides/submit-app-overview/#submission-process-for-sso-and-scim-integrations). To accelerate the registration process, contact your Auth0 or Okta representative. + +Since the Requesting App authenticates enterprise employees with Okta, you need to configure the application’s [sign-on policy](https://help.okta.com/en-us/content/topics/security/policies/policies-home.htm) in Okta. + +1. Go to **Applications > Applications** and select the application (e.g. Agent0). +2. Under **Sign On**, select **Edit** and add the Requesting App’s callback URL in the **Redirect URI** field. Adjust the Redirect URI’s value depending on the testing application you want to use. To learn more, read [Test the end-to-end XAA flow](/docs/secure/call-apis-on-users-behalf/xaa/test-xaa-flow). +3. Select **Save**. + +![](/docs/images/xaa/xaa_okta_req_app_sign_on_policy.png) + +### Assign Requesting Application to Test Users +Finally, allow your test user to log into the Requesting App in Okta. + +In the Okta Admin Console: + +1. Navigate to **Applications** and select the requesting application you created. +2. Select **Assign > Assign to People** and select your test user. +3. Select **Save**. + +![](/docs/images/xaa/xaa_okta_req_app_user_assignment.png) + +## Register the Resource App in Okta + +### Create Resource App in Okta +You must register your SaaS application in the Okta Integration Network (OIN) for it to be considered a valid Resource App. + +To register your SaaS application as a Resource App in Okta, you have two options: + +- For a quick test setup, we recommend using the **XAA Resource App** that is already registered in the OIN. In the Okta Admin Console, go to **Applications > Applications > Browse App Catalog** and search for `XAA Resource App`. Select it and add the integration. + +![](/docs/images/xaa/xaa_okta_browse_resource_app_in_oin.png) + +- During XAA Resource App install, configure **Issuer URL** to point to your Auth0 tenant. + +![](/docs/images/xaa/xaa_okta_resource_app_install.png) + +- You can also request the registration of a new application in the OIN from your Okta tenant. To learn more, read the [Submission process for SSO and SCIM integrations](https://developer.okta.com/docs/guides/submit-app-overview/#submission-process-for-sso-and-scim-integrations). To accelerate the registration process, contact your Auth0 or Okta representative. + + + + In a production environment, your enterprise customers will install your SaaS application from the OIN catalog during their IdP setup. + + + +- Since the Resource App authenticates enterprise employees with Okta, you need to configure the application’s sign-on policy in Okta. + +1. Go to Applications > Applications and select the application. +2. Under Sign On, select Edit and add your **Auth0 Tenant’s callback URL** in the **Redirect URI** field. +3. Select Save. + +![](/docs/images/xaa/xaa_okta_resource_app_details.png) + +Additionally, you must provide Okta with the issuer URL of your Auth0 tenant, which is associated with your Resource App. Requesting Apps use the issuer URL to request connecting to your Resource App. To learn more, read [Test the end-to-end XAA flow](/docs/secure/call-apis-on-users-behalf/xaa/test-xaa-flow). + +### Assign Resource Application to Test Users +Finally, allow your test user to log into the Requesting App in Okta. + +In the Okta Admin Console: + +1. Navigate to **Applications** and select the resource application you created. +2. Select **Assign > Assign to People** and select your test user. +3. Select **Save**. + +![](/docs/images/xaa/xaa_okta_resource_app_user_assignment.png) + +### Establishing connections between Requesting and Resource App + +1. From the Applications page, select the XAA Requesting app +2. Go to the Manage Connections tab +3. Under App granted consent, select Add requesting apps, select XAA Resource App, then Save +4. Under Apps providing consent, select Add resource apps, select XAA Resource App, then Save + +![](/docs/images/xaa/xaa_okta_req_res_apps_connection.png) + +### Configure an Okta Workforce Enterprise connection in Auth0 + +Use your **Resource App**’s `client_id` and `client_secret` to [create an Okta Workforce Enterprise connection](/docs/authenticate/identity-providers/enterprise-identity-providers/okta) in your Auth0 tenant. + +![](/docs/images/xaa/xaa_auth0_new_okta_workforce_connection.png) + +When creating the Okta Workforce Enterprise connection, activate the **Cross App Access - Resource Application** role. This enables your Resource App to accept ID-JAGs issued by the enterprise IdP associated with that connection, in this case, your Okta tenant. + +![](/docs/images/xaa/xaa_auth0_connection_xaa_enabled.png) + +After creating the Okta Workforce Enterprise connection, check that the **Callback URL provided by Auth0** in the connection's settings, matches the **Redirect URI** configure the sign-on policies of the **Resource App in your Okta** tenant. + +### Testing Connection in Auth0 +In the Auth0 Dashboard: + +- Navigate to **Authentication > Enterprise > Okta Workforce**: + - Enter the Okta Workforce Enterprise connection you created and select the **Applications** tab. Then, enable the Requesting App you created for the connection. + - Go back to the list of Okta Workforce connections. Select the three dots on the right for your connection and select **Try**. You will be redirected to authenticate in your Okta tenant to complete the login with your test user. + +![](/docs/images/xaa/xaa_auth0_try_okta_connection.png) + +- Login with the user you assigned to XAA Resource Applications + +![](/docs/images/xaa/xaa_okta_login.png) + +- Verify login was successful + +![](/docs/images/xaa/xaa_auth0_try_success.png) diff --git a/main/docs/secure/call-apis-on-users-behalf/xaa/manage-xaa-in-okta.mdx b/main/docs/secure/call-apis-on-users-behalf/xaa/manage-xaa-in-okta.mdx deleted file mode 100644 index 8f7d69b097..0000000000 --- a/main/docs/secure/call-apis-on-users-behalf/xaa/manage-xaa-in-okta.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -description: Learn how to manage XAA flows in the Okta Admin Console. -sidebarTitle: Manage XAA in Okta -title: Manage Cross App Access (XAA) in Okta ---- - -import { ReleaseStageNotice } from "/snippets/ReleaseStageNotice.jsx" - - - -Once you've finished setting up your end-to-end test environment, you can manage how valid XAA applications can connect to each other in the Okta Admin Console. - -![](/docs/images/xaa/manage_xaa_in_okta.png) - -In the Okta Admin Console: - -1. Navigate to **Applications > Applications** and select your Resource App (e.g. Todo0). -2. Under the **Manage Connections** tab, add: - - Requesting Apps: applications that can connect to your SaaS application - - Resource Apps: applications your SaaS application can connect to - -For the end-to-end test environment, add Agent0, or the application you want to use for testing, as an authorized Requesting App. 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-xaa-test-environment.mdx index fd5e00b9b0..489b264abd 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-xaa-test-environment.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) +sidebarTitle: Set up Auth0 XAA Environment +title: Set up Auth0 XAA Environment --- import { ReleaseStageNotice } from "/snippets/ReleaseStageNotice.jsx" @@ -15,41 +15,25 @@ import { ReleaseStageNotice } from "/snippets/ReleaseStageNotice.jsx" 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 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). - - - To set up your end-to-end test environment for 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). -- Configure how your Auth0 tenant federates with your customer’s enterprise IdP: In our test environment, the enterprise IdP will be your Okta test tenant, representing one of your enterprise customers. To learn more, read [Federate with the enterprise IdP and Organization configuration](#federate-with-the-enterprise-idp-and-organization-configuration). -- Manage Cross App Access in Okta: Configure agent-to-app and app-to-app connections in the Okta Admin Console. To learn more, read [Manage Cross App Access in Okta](/docs/secure/call-apis-on-users-behalf/xaa/manage-xaa-in-okta). - -The following image maps the responsibilities of the different personas in a production-ready XAA flow: - -![](/docs/images/xaa/xaa_persona_responsibilities.png) - -## Create and configure your Okta tenant - -To set up your end-to-end test environment for the Resource App, you need to create and configure your Okta tenant for Cross App Access. +- Configure how your Auth0 tenant federates with your customer’s enterprise IdP: In our test environment, the enterprise IdP will be your Okta test tenant, representing one of your enterprise customers. To learn more, read [Add Organization Support to XAA IdP](/docs/secure/call-apis-on-users-behalf/xaa/idp/federate-with-enterprise-idp). -- On the [Okta Developer website](https://developer.okta.com/signup/), sign up for an Okta Integrator Free Plan. Once you sign up, you should be redirected to your new Okta tenant. -- In the Okta Admin Console, navigate to **Settings > Features**. Under Early access features, enable **Cross App Access**. +{/* The following image maps the responsibilities of the different personas in a production-ready XAA flow: */} -![](/docs/images/xaa/okta_enable_xaa.png) +{/* ![](/docs/images/xaa/xaa_persona_responsibilities.png) */} -## Resource App setup +{/* ## Resource App setup */} -To set up your Resource App, you need to: +{/* To set up your Resource App, you need to: */} -- [Create the API in Auth0](#create-the-api-in-auth0) -- [Create the Resource App in Auth0](#create-the-resource-app-in-auth0) -- [Register the Resource App in Okta](#register-the-resource-app-in-okta) +{/* - [Create the API in Auth0](#create-the-api-in-auth0) */} +{/* - [Create the Resource App in Auth0](#create-the-resource-app-in-auth0) */} +{/* - [Register the Resource App in Okta](/docs/secure/call-apis-on-users-behalf/xaa/idp/manage-xaa-in-okta#register-the-resource-app-in-okta) */} -### Create the API in Auth0 +## Create the API in Auth0 @@ -65,35 +49,17 @@ After you’ve created the API, you can optionally set its audience as the **Def You can also use [API Access Policies for Applications](/docs/get-started/apis/api-access-policies-for-applications) to granularly control which applications are granted access to your API for which scopes. -### Create the Resource App in Auth0 - - - -If your Auth0 tenant already has one or several applications ready to log into your SaaS application, you can skip this section. - - - -In the Auth0 Dashboard, [create an application](/docs/get-started/auth0-overview/create-applications), such as a regular web app, SPA, or native app, that serves as the primary interface for end-users to access your SaaS application functionality. - -### Register the Resource App in Okta - -You must register your SaaS application in the Okta Integration Network (OIN) for it to be considered a valid Resource App. +{/* ### Create the Resource App in Auth0 */} -To register your SaaS application as a Resource App in Okta, you have two options: +{/* */} -- For a quick test setup, we recommend using the Todo0 application that is already registered in the OIN. In the Okta Admin Console, go to **Applications > Applications > Browse App Catalog** and search for `Todo0`. Select it and add the integration. +{/* If your Auth0 tenant already has one or several applications ready to log into your SaaS application, you can skip this section. */} -![](/docs/images/xaa/xaa_browse_todo0_in_oin.png) +{/* */} -- You can also request the registration of a new application in the OIN from your Okta tenant. To learn more, read the [Submission process for SSO and SCIM integrations](https://developer.okta.com/docs/guides/submit-app-overview/#submission-process-for-sso-and-scim-integrations). To accelerate the registration process, contact your Auth0 or Okta representative. +{/* In the Auth0 Dashboard, [create an application](/docs/get-started/auth0-overview/create-applications), such as a regular web app, SPA, or native app, that serves as the primary interface for end-users to access your SaaS application functionality. */} - - -In a production environment, your enterprise customers will install your SaaS application from the OIN catalog during their IdP setup. - - - -Additionally, you must provide Okta with the issuer URL of your Auth0 tenant, which is associated with your Resource App. Requesting Apps use the issuer URL to request connecting to your Resource App. To learn more, read [Test the end-to-end XAA flow](/docs/secure/call-apis-on-users-behalf/xaa/test-xaa-flow). +{/* For Okta-specific configuration, see [Register the Resource App in Okta](/docs/secure/call-apis-on-users-behalf/xaa/idp/manage-xaa-in-okta#register-the-resource-app-in-okta). */} ## Requesting App setup @@ -106,7 +72,7 @@ In a production environment, you configure each Requesting App once to enable it To set up your Requesting App, you need to: - [Create the Requesting App in Auth0](#create-the-requesting-app-in-auth0) -- [Register the Requesting App in Okta](#register-the-requesting-app-in-okta) +- [Register the Requesting App in Okta](/docs/secure/call-apis-on-users-behalf/xaa/idp/manage-xaa-in-okta#register-the-requesting-app-in-okta) ### Create the Requesting App in Auth0 @@ -119,98 +85,14 @@ To [create an application](/docs/get-started/auth0-overview/create-applications) ![](/docs/images/xaa/xaa_create_regular_web_app.png) +- In the application details, note the **Client ID** of the application. This is required during [Register the Requesting App in Okta](/docs/secure/call-apis-on-users-behalf/xaa/idp/manage-xaa-in-okta#register-the-requesting-app-in-okta). + +![](/docs/images/xaa/xaa_req_app_details.png) + - Once you’ve created the application, scroll to **Settings** and enable the **Cross App Access** toggle. ![](/docs/images/xaa/allow_xaa_auth0_app.png) Once you’ve created and configured your application, you must provide Okta with the application’s `client_id` and the issuer URL of your Auth0 tenant. This enables the connection between the Requesting App, identified by the `client_id`, and the Resource App, identified by the issuer URL. To learn more, read [Test the end-to-end XAA flow](/docs/secure/call-apis-on-users-behalf/xaa/test-xaa-flow). -### 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 will install the Requesting App from the OIN catalog during their IdP setup. - - - -You must register the application in the Okta Integration Network (OIN) for it to be considered a valid XAA Requesting App when using Okta as the enterprise IdP. - -To register the Requesting App in Okta, you have two options: - -- For a quick test setup, we recommend using the Agent0 application that is already registered in the OIN. In the Okta Admin Console, go to **Applications > Applications > Browse App Catalog** and search for `Agent0`. Select it and add the integration. - -![](/docs/images/xaa/xaa_select_agent0_in_oin.png) - -- You can also request the registration of a new application in the OIN. To learn more, read the [Submission process for SSO and SCIM integrations](https://developer.okta.com/docs/guides/submit-app-overview/#submission-process-for-sso-and-scim-integrations). To accelerate the registration process, contact your Auth0 or Okta representative. - -Since the Requesting App authenticates enterprise employees with Okta, you need to configure the application’s [sign-on policy](https://help.okta.com/en-us/content/topics/security/policies/policies-home.htm) in Okta. - -1. Go to **Applications > Applications** and select the application (e.g. Agent0). -2. Under **Sign On**, select **Edit** and add the Requesting App’s callback URL in the **Redirect URI** field. Adjust the Redirect URI’s value depending on the testing application you want to use. To learn more, read [Test the end-to-end XAA flow](/docs/secure/call-apis-on-users-behalf/xaa/test-xaa-flow). -3. Select **Save**. - -![](/docs/images/xaa/agent0_sign_on_policy.png) - -Finally, allow your test user to log into the Requesting App in Okta. - -In the Okta Admin Console: - -1. Navigate to **Applications** and select the application (e.g. Agent0). -2. Select **Assign > Assign to People** and select your test user. -3. Select **Save**. - -## Federate with the enterprise IdP and Organization configuration - - - -In a production environment, you configure each of your enterprise customers once to federate it with your Auth0 tenant. Auth0 will add support for [Self-Service SSO](/docs/authenticate/enterprise-connections/self-service-enterprise-configuration) in later versions, enabling you to delegate XAA configuration to your enterprise customers as part of SSO setup. - - - -You must federate your Auth0 tenant, acting as the authorization server for your Resource App, with your enterprise customer's Okta tenant. This federation establishes cryptographic trust, allowing your application to validate and accept signed assertions (ID-JAGs) issued by the customer's IdP. - -To test the end-to-end XAA flow for multiple enterprise customers connected to your Resource App, you can repeat the steps in this section for multiple Okta Workforce Enterprise connections in your Auth0 tenant. Each connection maps to a different Okta test tenant, where each tenant represents a different enterprise customer. - -### Configure an Okta Workforce Enterprise connection - -Use your Resource App’s `client_id` and `client_secret` to [create an Okta Workforce Enterprise connection](/docs/authenticate/identity-providers/enterprise-identity-providers/okta) in your Auth0 tenant. - -When creating the Okta Workforce Enterprise connection, activate the **Cross App Access - Resource Application** role. This enables your Resource App to accept ID-JAGs issued by the enterprise IdP associated with that connection, in this case, your Okta tenant. - -![](/docs/images/xaa/xaa_new_okta_workforce_connection.png) - -After creating the Okta Workforce Enterprise connection, copy the callback URL provided by Auth0 in the connection's settings. You need the callback URL to configure the sign-on policies of the Resource App in your Okta tenant. - -In the Okta Admin Console: - -1. Navigate to **Applications > Applications** and select the application (e.g. Todo0). -2. Under **Sign On** settings, select **Edit** and add the callback URL in the **Redirect URI** field. -3. Select **Save**. - -![](/docs/images/xaa/xaa_advanced_sign_on_settings.png) - -To test the Okta Workforce Enterprise connection, create a test user and give it permission to log into the Requesting App. - -In the Okta Admin Console: - -- Navigate to **Applications** and select the application (e.g. Agent0). -- Select **Assign > Assign to People** and select your test user. -- Select **Save**. - -In the Auth0 Dashboard: - -- Navigate to **Authentication > Enterprise > Okta Workforce**: - - Enter the Okta Workforce Enterprise connection you created and select the **Applications** tab. Then, enable the Requesting App you created for the connection. - - Go back to the list of Okta Workforce connections. Select the three dots on the right for your connection and select **Try**. You will be redirected to authenticate in your Okta tenant to complete the login with your test user. - -![](/docs/images/xaa/xaa_create_okta_workforce_connection.png) - -### Configure an Organization - -Optionally, if you want an enterprise customer to use Organizations, [create an Organization](/docs/manage-users/organizations/configure-organizations/create-organizations) and [enable the Okta Workforce Enterprise connection](/docs/manage-users/organizations/configure-organizations/enable-connections) for that Organization. This automatically associates access tokens generated using XAA, in the scope of this connection, to the corresponding `org_id` if the target user is a member of the Organization. - -![](/docs/images/xaa/xaa_enable_connection.png) - -You can also configure the Requesting App’s [Organization behavior](/docs/manage-users/organizations/configure-organizations/define-organization-behavior) to set whether it is required or allowed to use Organizations. We recommend that you start testing with **Both**, which allows users to log in as an Organization member or sign up with a personal account. - -![](/docs/images/xaa/xaa_organizations_both.png) +For Okta-specific configuration, see [Register the Requesting App in Okta](/docs/secure/call-apis-on-users-behalf/xaa/idp/manage-xaa-in-okta#register-the-requesting-app-in-okta). 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..87df81388c 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 @@ -17,7 +17,7 @@ To test the end-to-end XAA flow, you need to verify that your Auth0 tenant can a 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](/docs/secure/call-apis-on-users-behalf/xaa/set-up-xaa-test-environment#register-the-requesting-app-in-okta). +- 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/idp/manage-xaa-in-okta#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.