Skip to main content

Arist SSO Overview

Learn how single sign-on lets people sign in to the Arist web app with the credentials your identity provider already manages, which providers the self-service setup supports, and how the rollout runs.

Platform access level: Org Admins


Single sign-on lets the people who sign in to the Arist web app use the credentials your identity provider already manages, brokered through Auth0. Your IT team sets it up through a guided self-service link, with no custom engineering on either side. This overview is written for Org Admins and IT stakeholders who plan and run an SSO rollout.


1. How Arist brokers SSO through Auth0

Arist uses Auth0, Okta's identity platform, as the broker between your identity provider and Arist. Your provider and Arist never share passwords directly, and each customer gets its own isolated Auth0 organization, which keeps your users and login experience separate from every other Arist customer. Auth0 supports both OIDC and SAML connections, so you can use the protocol your provider already runs, and your IT team configures the connection without engineering work from Arist.

Note: SSO governs how the users in your organization sign in to Arist as end users. It is separate from your organization API key, which governs how your systems call the Arist API. Keep the two credentials distinct.


2. Who SSO is for

SSO is for the Org Admins and platform users who sign in to the Arist web app to build content and manage settings. It is optional and designed for those teams.

Your learners do not sign in. They receive courses through delivery methods such as Microsoft Teams, Slack, SMS, and email, so SSO does not change anything about how a learner takes a course.

Note: When SSO is enabled, the passcode sign-in option is no longer available, because entering a work email address automatically redirects the user to your identity provider.


3. Supported identity providers

Auth0's self-service setup supports the providers below. Each one has provider-specific written instructions inside the setup assistant, so you follow the exact steps for your provider during the guided flow.

  • Okta Workforce Identity

  • Microsoft Entra ID (Azure AD)

  • Google Workspace

  • Microsoft ADFS

  • PingFederate

  • Keycloak

  • Generic OIDC or Generic SAML, for any other standards-based provider

Note: For a provider that is not listed, or for Active Directory or LDAP, check with your Arist contact, since those can use a different connection method than the self-service flow.


4. Self-service setup process

Your IT team completes the connection through a secure self-service link, not through Arist engineering. The link is valid for 10 entries or 5 days, whichever comes first.

  1. Tell your Arist Implementation Manager you want to enable SSO.

  2. Receive the secure self-service link from your Arist contact.

  3. In the setup assistant, select your identity provider from the supported list.

  4. Create the application or connection in your identity provider, and enter the values the assistant gives you.

  5. Map your user attributes, or claims, such as email, so Arist can identify each user.

  6. Assign the users or groups who should have access, then test a sign-in from the assistant.

  7. Email your Arist contact to confirm the setup is complete.

Note: Completing the assistant automatically creates or updates the enterprise connection in Arist's Auth0 tenant, so there is no separate step in Arist once you finish.


5. Information your IT team provides

What you exchange with Auth0 depends on whether your connection uses SAML or OIDC. The table shows what you provide and what Auth0 gives back for you to enter in your provider.

Connection type

What you provide to Auth0

What Auth0 gives you

SAML

Your identity provider sign-in (SSO) URL, the identity provider entity ID or issuer, the X.509 signing certificate, and the attribute you send as the sign-in identifier such as email

The Assertion Consumer Service (ACS) URL and the service provider entity ID (audience) to register in your provider

OIDC

Your issuer or discovery URL, the client ID, the client secret, and the scopes that release the sign-in identifier

The redirect (callback) URL to register in your provider

The setup assistant collects details such as your domain, client ID, and client secret, and shows written instructions specific to the provider you select, so you configure the exact fields for your provider inside the guided flow rather than from a static list.


6. SP-initiated login and the IdP-initiated limitation

Arist supports SP-initiated login today, where the user starts at Arist, enters their work email, and is routed to your provider to sign in. Native IdP-initiated login, where the user starts from a tile in your own dashboard, requires SAML. OIDC connections, including Microsoft Entra ID and Okta configured through OIDC, do not offer a native IdP-initiated flow.

Important: If you want a start from your own dashboard experience without moving to SAML, point a dashboard tile at an Arist login link. It looks similar to your users, but is still technically SP-initiated.


Related articles

  • Arist Integrations Guide

  • How Arist Builds Data Integrations

Note: Need help at any point? Reach out to your Arist Customer Success contact, or email [email protected].

Did this answer your question?