Skip to main content
All CollectionsHow ToSSO
Configure AuthO SSO and Azure Connection
Configure AuthO SSO and Azure Connection

Set up Auth0 with Entra ID (formerly Azure AD) for SSO in Torq; create applications, group claim rules, and configure SSO in Torq settings.

Updated over a week ago

This guide assumes that you already have Azure Connection configured in Auth0. If you still need to configure an Azure integration with Auth0.

After you configure the Azure integration, make sure under General the Extended Attributes settings are enabled. Specifically, the Get user groups setting.

Configure AuthO

In Auth0, you'll create a new application and create a new rule in the Auth Pipeline.

Create a new application

1. Type a meaningful name for the application, for example, Auth0 Torq. Make sure you select the application type Regular Web Applications and click Create.

Screenshot of creating an Azure app.

2. Go to the Connections tab and select the relevant connections that you want to connect to Torq. In our example, we have an integration with Azure called LeonidAzure.

Screenshot of configuring connection in the Azure app.

3. Go back to the Settings tab and under Allowed Callback URLs enter https://app.torq.io/__/auth/handler or EU: https://app.eu.torq.io/__/auth/handler (this is the Login redirect URL provided by Torq).

4. Make note of the settings under the Basic Information section. You will need them when configuring an SSO connection in Torq.

1. Domain

2. Client ID

3. Client Secret

Create a new rule in Auth Pipeline to pass ID group claims

Torq can use custom claims that are passed via the ID Token to assign Roles to the logged-in user. These claims are not provided by Auth0, based on the information from Entra ID by default. To add them to the ID Token, we must create a new Auth Pipeline Rule in Auth0 that will add them there.

Usually, we are interested in the Groups attribute since role assignments are most commonly used by existing Entra ID groups.

1. Go to Auth Pipeline > Rules.

2. Click Create > Empty Rule.

3. In the Name field enter: Torq Token Group Enrichment

4. In the Script field enter the below code snippet. Make sure to replace

with the Client ID of the application you created in the previous step. This will ensure the enrichment occurs only on the Torq application.

function enrichTorqToken(user, context, callback) {
    if (context.clientID !== '') {
    return;
  }
  const namespace = "https://torq.io/";
    context.idToken[namespace + 'groups'] = user.groups;  callback(null, user, context);
}

Set up SSO in Torq

Perform these steps in Torq.

  1. Go to Settings > SSO Login.

  2. In the IdP Connection section click Add. Select the Open ID Connect protocol.

Field

Value

Client ID

The client ID you copied earlier when creating the app.

Client secret

The client secret you copied earlier when creating the app.

Issuer URL

The domain you copied earlier when creating the app. https://

Screenshot of setting up an IdP connection in Torq.

  • When using version 16.1 or newer of the Safari browser you have to make sure the Login redirect URL in Torq is https://app.torq.io/__/auth/handler or EU: https://app.eu.torq.io/__/auth/handler. If this isn’t the case, you should contact your support representative and ask them to update this URL for your Torq workspace before you continue. If you already set up SSO for your Torq workspace, you have to update the Login redirect URL you provided to your IdP after the support representative updates the URL for your Torq workspace.

  • Contact Torq support if you need to change the Login redirect URL.

3. To define claim mappings, click Add in the Claims mapping section.

autho-sso-claims-mapping


The example above assigns the members of the Entra ID group "Security Administrators" full control over the Torq.io workspace by assigning the Owner role. You can create multiple Claim Mapping rules for different Entra ID groups, assigning them the relevant roles, such as but not limited to Owner, Contributor, Creator, Operator, or Viewer in Torq.io.


The mappings are interpreted in an ordered, top-down manner. The mapping assigning the highest privilege should be listed first, and the other mappings should be listed in descending privilege order. A user is assigned a role according to the first match, disregarding any following assignments.

Did this answer your question?