Overview

Single Sign-On (SSO) lets your users log into Torq using your organization’s identity provider (IdP) instead of a separate Torq username and password. This improves security and usability by centralizing authentication and can support automatic user provisioning based on claims or attributes sent by the IdP.

This article provides generic SAML 2.0 and OpenID Connect (OIDC) configuration instructions, intended for customers using identity providers that do not have dedicated Torq documentation.

If you are using a supported IdP with vendor-specific documentation, follow the relevant guide available in the Set Up Single Sign-On (SSO) collection.

Prerequisites

Permissions: You need workspace Owner permissions in Torq to configure SSO.
Test users: Have at least two test users ready, especially one that won’t be the same as the account you use to set up SSO, this avoids lockout.
Protocols supported: Torq supports both SAML 2.0 and OpenID Connect (OIDC) with a variety of IdPs (e.g., Okta, Microsoft Entra ID, OneLogin, JumpCloud). When both options are available in your IdP, Torq recommends using OIDC because it’s simpler to implement and operate, and it supports IdP-initiated SSO in Torq.
Best practice: Start in a staging or test workspace if possible.
Register support contacts first: Email sent to support@torq.io from an address without a Torq support portal account is silently discarded. If SSO breaks after configuration and your team cannot log in to submit a ticket through the portal, you may be unable to reach support. Before starting, ensure at least one team member is registered on the Torq support portal.

Important!

Before getting started, make sure you understand how to prevent user lockouts by reviewing this KB article.

Configure an application in your IdP

You must first create an app or connection in your IdP so it can issue authentication assertions or tokens to Torq. In some IdPs, this may also be referred to as creating a New SSO Provider. Common fields you’ll set in your IdP (see the Enter IdP details section below) are:

Redirect/Assertion Consumer URL (provided by Torq)
Audience / Entity ID
Issuer URL, Client ID, Client Secret
Public Certificate
Requests scopes
User Attributes / Claims (e.g., email, name, groups)

The exact steps depend on the IdP and protocol you choose (SAML vs. OIDC), but the goal is the same: configure your IdP so it trusts Torq and can send authenticated sessions and user attributes to it.

Set up SSO in Torq

Start the SSO setup

Important!

Only one SSO configuration can be active per workspace at a time. Saving a new configuration, including switching between SAML and OIDC, immediately replaces the existing one. If your workspace already has a working SSO setup, do not proceed until you are ready to reconfigure and re-validate from scratch.

Open the SSO settings: In Torq, go to Settings > Security > SSO.
Add a new SSO provider: Click Configure SSO.
Choose the protocol and identity provider: Select SAML 2.0 or OpenID Connect, then choose your IdP (Okta, Entra ID, etc.). If you’re configuring a generic provider, select Other.
Continue setup: Click Next.

Enter IdP details

Paste the values from your IdP into Torq’s SSO configuration form. The required fields depend on your identity provider and whether you’re using SAML or OIDC.

Parameter	Value
Login Redirect URL	US: `https://app.torq.io/__/auth/handler` EU: `https://app.eu.torq.io/__/auth/handler`
Audience Restriction	torq.io
Sign-on URL	Your IdP endpoint (where to send users for authentication during SSO)
Client ID	A unique identifier assigned by your IdP
Client Secret	A confidential key generated by your IdP
Issuer URL	A URL that identifies your IdP as the issuer of the authentication response
Public certificate	A signing certificate from your IdP used to verify the authentication responses

Advanced settings (OIDC only)

Parameter	Value
Requested Scopes	`groups` Without this, your IdP won’t send any groups claims back to Torq.
Grant type	`implicit flow (id_token)` so it matches the configuration defined in your IdP.
Code flow	A secure, two-step process where an authorization code is exchanged for tokens on the server side
Implicit flow	Tokens are returned directly in the browser
Send login hint to SSO provider	Optionally sends the user’s email or username as a login hint to the SSO provider

Configure claims (user attributes)

You must map at least one claim such as email from your IdP to a Torq role. This mapping determines how users authenticated via SSO are assigned roles in Torq. Without a correct email mapping, users may be unable to access the workspace.

Add claim mapping rules: In the Claims Mapping section, click Add Claim to create a new rule.
- The wizard automatically offers the first mapping, email, marked as recommended.
- This field is auto-filled with the email address of the current user (the Owner performing the setup).
- You can optionally edit this initial mapping before saving.
- After editing, click Add to move the mapping into the saved section.
Provide mapping details: For each rule, define the following:
- Claim Name: The field from your IdP (for example, email or groups).
- Claim Value: The expected value of the claim (case-sensitive).
- Assigned Role: The Torq role to assign (for example, Admin, Editor, Viewer).
Organize claim priority:
- Mappings are evaluated top-down.
- Place the claim with the highest privilege role at the top.
- Lower-privilege mappings should follow in descending order.
- A user’s role is determined by the first matching claim.
Save configuration: After defining all required mappings, click Save to complete the setup.

Test the configuration

Test login: Sign in via SSO in a separate browser session (or an incognito window) using a test user.
Verify role assignment: Confirm the user receives the expected role based on your claims mapping.

Roll out to your team

Once verified:

Communicate the new login process to your users.
Optionally remove legacy (non-SSO) login options if desired.
Monitor for any authentication issues and adjust claim mappings if needed.

Best practices

Avoid lockouts: Before enabling SSO, designate one local Owner account that will never be used to sign in through SSO and store its credentials securely. If a user authenticates via SSO and no claim mappings are matched, their local account is removed from Torq and they lose access to the Torq app. They will only be able to access Torq Interact forms. A local account that has never signed in through SSO is unaffected and provides a recovery path if the SSO configuration breaks. For more details, see Configure SSO for Torq: Boost Security and Efficiency.
Multiple domains: If your organization uses multiple email domains, check Torq support for additional configuration steps.
Group-based roles: Many IdPs let you include group membership in tokens; these can be mapped to roles in Torq.

Single Sign-On Setup (Generic Guide)