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.
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
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: EU: |
Audience Restriction | |
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 |
|
Grant type |
|
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,
emailorgroups).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: Make sure the email claim is correct before enforcing SSO only.
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.