Introduction

Your platform can integrate with Auth0, a multi-layer Identity Provider. With this integration, you can allow users to log into their Docebo platforms using credentials from active sessions of other web platforms. This integration can be used with subdomains, for those using Docebo’s Extended Enterprise app.

Please note: Auth0 custom domains are not supported by Docebo for Auth0 authentication.

Activating the app in Docebo

Activate the Auth0 app as described in the Managing Apps & Features article of the Knowledge Base. The app is listed in the Single Sign On tab.

Once the app is activated, you can begin the configuration.

Configuring the integration in Auth0

Best practice: When an SSO integration and a custom domain, configured in Domain Management, are set up at the same time, it is strongly suggested to configure the custom domain first. The endpoint URLs needed for the SSO integration are dependent on the URL of the platform.

Begin by logging into your Auth0 account, then press the New Application button in your Dashboard. In the pop-up box, add your app’s name, then choose the client type. For this integration, the client type does not matter. Refer to the Auth0 documentation (opens in a new tab) for more information about client types. Press Create when finished.

Once created, move to the Settings tab. Here, you need to pick up the Domain, Client ID, and Client Secret fields that were automatically generated. Click on the Review Client Secret button to the right of the Client Secret field. These three fields need to be inserted into the corresponding fields in the Settings page for Auth0 in your platform.

Then, you need to insert the URL of your platform in your Allowed Callback URLs field as well as in the Allowed Web Origins field. For the Allowed Callback URLs field, you need to insert some information after your platform URL, it should look like this:

https://mylmsurl.docebosaas.com/learn/auth0/callback

If you activated Auth0 for your Mobile App, when rebranding your app with the Docebo Branded Mobile App Publisher, remember to set the Package Name (for Android) and the Bundle ID (for IOS) in the Allowed Callback URLs field. The callback URLs for mobile rebranded apps should look like this:

com.yourcompany.yourapp

Next, scroll down and press the Show Advanced Settings item in the Settings tab for the client in Auth0. In the Advanced Settings area, select the Certificates tab, then copy all of the text from the Signing Certificate field and paste it into the corresponding field on the Settings page for Auth0 in your platform. You can also download the certificate for reference, if needed, but it is not mandatory. The rest of the configuration now takes place directly in your platform.

Configuring the app in Docebo

Access the Admin Menu from the gear icon in the header, find the Auth0 section in the menu, then press the Manage subitem. On this page, insert the Domain, Client ID, Client Secret, and Signing Certificate that you retrieved directly from Auth0.

Then, select the username attribute from Auth0 that will be used to match the user to a user profile in Docebo. Simply type in the attribute (i.e. Username, email address, unique user field) into the corresponding text box.

If you do not want to configure the SSO behavior, logout behavior, or user provisioning, press Save Changes. 

SSO behavior

To configure the SSO behavior, you can flag between two different options. Choose whether you want to show the standard platform login page, or if you want to automatically redirect to the Identity Provider. If you flag the first option, you can then flag whether you want to show the SSO button on your platform’s login page.

If you flag the option for an Automatic redirect to Identity Provider, you can set a specific logout landing page when your users log out of the platform instead of keeping the standard logout page. Use the text box to type in the URL of the logout landing page.

Logout behavior

In the Logout Behavior section, you can flag the option for the user to automatically be logged out of the Identity Provider when he or she logs out of the platform.

When this option is selected, you have to place the URL of your platform on the allow list in Auth0, or your users will not be allowed to log out. The platform URL must be declared in two areas of your Auth0 account, so log into your Auth0 account and perform the following actions:

• Click on Applications in the left menu, find your Docebo application in the list and click on the gear icon in the application row to access the Settings page. Move to the Allowed Logout URLs section and type the URL of your platform followed by /auth0. For example:
  

  https://myplatform.docebosaas.com/auth0

• Next, move to your profile menu by clicking on your avatar in the top right corner, and select Settings. Move to the Advanced tab and type your platform URL in the Allowed Logout URLs section. For example:
  

  https://myplatform.docebosaas.com

When using a custom domain, configured in Domain Management, enter both the URL of your custom domain and the docebosaas URL.

User provisioning

In order to properly perform user provisioning for this integration, you must first create Actions in Auth0 in order to expose the Auth0 users’ claims so that Docebo can use this data to configure the user provisioning. Please see the Auth0 documentation on Actions to learn more (opens in a new tab).

Tip: If you were previously using Auth0 Rules, it is strongly recommended to create new actions, rather than automatically migrate them with the option offered by Auth0.

Once you've created the proper Actions, you can configure the user provisioning in your platform.

In your platform, it allows you to instantly create a user who is present in your Identity Provider but is not yet present in the platform database. Begin by flagging the Enable option. You can also flag the option to lock provisioned user fields, meaning that users cannot edit details in their user profiles that have been created via Auth0. When editing the user profile, the options will be greyed out.

If you have users that already exist in both databases, you should flag the option to update the user information for the existing users. Please note that not flagging these options result in needing to manually register (enable option) or update your users (update information) in the platform.

Now, you need to specify which additional fields you want to associate between your Identity Provider and Docebo, then match the names of the fields in Docebo with the name of the fields in the Identity Provider (attribute statement). Please note that each field must be unique, meaning that you cannot apply the same claim to multiple fields.

In the text box, type in the name of the additional field in the platform, then press the Add button. The additional field will appear in a list below, with the field name and field category automatically filled in by your platform. Insert your Identity Provider attribute statement into the corresponding text box.

When you’re finished, press Save Changes.

Notes about user provisioning

• If you wish to populate the country user additional field via SSO, an acceptable value would be either the Country ID or Country Name as listed in the article titled List of ISO 3166-1 Countries.
• The Language user attribute is not supported when provisioning users.

Auth0 for Extended Enterprise clients

If you want to set up Auth0 for a specific client that you’ve created using the Extended Enterprise app, access the Admin Menu, find the Extended Enterprise section, then press the Manage subitem. Find your client in the list, then press the gears icon in the client’s row. Then, reach the Auth0 Settings tab on the left side of the page. Now, follow the steps outlined above to fill in the settings page.

Logging in using Auth0 credentials

To log in to your platform using your Auth0 credentials, press the Login button on the platform’s sign-in page, then press the Auth0 item in the pop-up box.

Configuring Auth0 for the Go.Learn app

If you're using Auth0 for SSO on Docebo’s Go.Learn app, you need to configure the Application Type and Allowed Callback URLs field in Auth0 in order for your learners to log into the app using Auth0.

The Application Type must be set to Native, and you must add the following URLs into the Allowed Callback URLs section (replacing {AUTH0_DOMAIN} with your own Auth0 domain, using the FQDN - Fully qualified domain name):

com.docebo.eolo.staging://{AUTH0_DOMAIN}/ios/com.docebo.eolo.staging/callback

com.docebo.eolo.staging://{AUTH0_DOMAIN}/android/com.docebo.eolo.staging/callback

Please note: You should configure these fields as soon as possible to ensure that your users are able to access the Go.Learn app using Auth0. As of April 2, 2019, if you have not configured these fields properly, your users will not be able to access Go.Learn using Auth0 SSO.

Authentication flow

As of October 26, 2021, Docebo has implemented a short-lived token in order to provide better security:

Previous authentication flow

Before October 26, 2021, the Docebo platform would send a request to the Identity Provider (IdP) and receive a persistent access token.

Each SSO has a slightly different process, but all of them return a link to Docebo with the access token in the URL:

https://mylms.docebosaas.com/learn/home;type=oauth2_response;reenter_cc=0;access_token=9b8de7ed2af145dee78aa4282bf1d3b17baf02cd;expires_in=3600;token_type=Bearer;scope=api

Short-lived token authentication flow

The updated authentication flow provides added security by replacing the IdP provided single-use short-lived token with an internally used access token:

Each SSO has a slightly different process, but all of them return a link to Docebo with the short lived token in the URL. The short lived token is a one use short lived (with a lifespan of 30 seconds) token that can be exchanged for real credentials:

https://mylms.docebosaas.com/learn/signin;type=token_exchange;exchange_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSU

Docebo automatically and internally using POST calls exchanges it for the real access token. This increases security but does not change the overall behavior of the SSO.