TABLE OF CONTENTS
- What is Single Sign-On (SSO)?
- Key Benefits of Single Sign-On (SSO)
- Eligibility & Prerequisites
- Navigation and Access
- Setup Flow
- Testing and Enabling SSO
- Troubleshooting Common Errors
- Current Limitations & Troubleshooting Common Errors
- Add users from the SSO identity provider’s (IDP) user database to GHL
- Scopes Explained
- Frequently Asked Questions
What is Single Sign-On (SSO)?
Single Sign-On (SSO) is an authentication method that connects TWIM CRM to an external Identity Provider (IdP) that speaks the OpenID Connect (OIDC) standard. After SSO is configured, users are redirected to your IdP, authenticate once, and are passed back to TWIM CRM with a verified token—eliminating separate usernames and passwords inside TWIM CRM and giving you centralized control over identity. Agencies on the $497 plan with a white-label domain can enable one IdP connection per agency to power SSO across every sub-account.
Key Benefits of Single Sign-On (SSO)
- One-click access—users sign in once and seamlessly reach all their TWIM CRM accounts.
- Stronger security—password policies, MFA, and conditional access rules stay inside your IdP.
- Branded experience—hide email/password and social logins so your logo is the only thing clients see.
- Centralized user lifecycle—suspend or delete a user in the IdP to revoke TWIM CRM access instantly.
- Audit-ready—login events flow into the IdP’s reporting for compliance and governance.
Eligibility & Prerequisites
Agencies must meet all of these conditions before SSO can be enabled:
- Active $497/month agency subscription.
- A configured white-label domain (SSO only appears on the white-labeled login page).
- Exactly one IdP integration per agency (multiple IdPs are not supported).
- IdP must support OpenID Connect; SAML is not currently supported.
- Users must already exist in TWIM CRM or be created through the Users API with their externalUserId.
Navigation and Access
Navigate to: Company Settings in Agency Level → Single Sign-On (SSO). All agency admins can view and configure SSO. You’ll see an “Enable SSO” CTA to initiate the setup flow.
Setup Flow
**Step 1:**Client ID & Secret
- Method of Authentication: Locked to OIDC (SAML will be supported in the future).
- Client ID: The identifier issued by your IdP.
- Secret: A secure key generated by your IdP, used by TWIM CRM to prove its identity when making requests.
Step 2: OIDC Configuration
You can configure this automatically or manually:
-
**
Automatic Discovery (recommended)**: Select Yes for “Use OIDC Config URL.”. Enter the OIDC Config URL from your IdP (usually: https://<idp>/.well-known/openid-configuration). -
Manual Configuration: Enter the following endpoints from your IdP:
- Authorization URL
- Token Endpoint
- User Info Endpoint
Additional notes:
- Scopes: Define what data TWIM CRM can retrieve. At a minimum, OpenID is required. Adding a profile and email is recommended.
- Redirect URL: Prefilled by TWIM CRM. If not, it should follow this pattern:
https://<your-whitelabel-domain>/login/sso.
This Redirect URL must be whitelisted in your IdP configuration. Editing the Redirect URL is not advisable unless correcting it to match the correct pattern.
Step 3: User Details Mapping
We need to link the user information from your IdP to TWIM CRM so the same user is correctly recognized across both systems.
Fields to complete:
-
**Remote ID Field (required):**The unique user ID from your IdP (e.g., sub in OIDC, oid in Azure). Ensures consistent identification of the same user across platforms.
-
ID Field (optional): The TWIM CRM user ID. Use if you want to map directly to existing TWIM CRM users.
-
Email Field: The user’s email address field in your IdP (e.g., email, userPrincipalName). Helps confirm and map user identities.
- Please make sure that this field is unique to each user in your system.
- This is what we will use to update the user’s email in our data.
-
Email Verified Field (required): Ensures the email has been validated by your IdP. Prevents unverified or spoofed accounts from accessing TWIM CRM. Ex: email_verified.
Step 4: Review & Finish
Double-check all entries. Save the configuration. After completing the setup, you’ll see three collapsible sections:
- SSO Configuration – Displays the configuration you entered.
- Test Status – Allows you to run an automated test to validate the setup. Until a test passes successfully, you cannot enable SSO.
- Additional Settings– Includes toggles to enable SSO for the agency and optionally hide other login methods (Email and Google). Proceed to testing.
Testing and Enabling SSO
After configuring SSO, testing the config is mandatory. Unless a successful test is carried out, SSO Toggle cannot be turned on.
To perform a test:
-
In the test section, click on the “Start Test” button to initiate a new Test.
-
Or, click on the three-dotted menu from top right, click on the “Test Configuration” option.
- This will mimic the SSO Login flow, take the tester to the IdP, and prompt you to log in.
- Once done, this will redirect you back to the Company Settings SSO tab with updated test status.
- If successful, you can proceed to enabling SSO. If it fails, you will see some error message to prompt what could be wrong. A list of common errors has been attached.
- If there are any issues in the IdP Config, you will see the errors with your IdP.
- NOTE: If the SSO Config is updated after performing a test, all the tests will be marked as “EXPIRED”. The test will no longer be considered valid, all your SSO toggles will get reset. This will require you to perform a new Test to enable SSO for your agency again.
Troubleshooting Common Errors
Editing or Deleting an Existing Configuration: Editing an SSO config invalidates prior test results and disables SSO by default. You must re-test and re-enable.
-
The Hide other login options toggle will not work until SSO is enabled.
-
Deleting an SSO config (from the three-dotted menu):
-
Resets additional settings.
-
Expires test results.
-
Disables SSO for all users.
Provider-Specific Guides
Auth0
- Create a Regular Web Application in Auth0.
- Copy Client ID and Secret into TWIM CRM.
- Add TWIM CRM Redirect URL to Auth0 Allowed Callback URLs.
- Config endpoint→ https://YOUR_DOMAIN/.well-known/openid-configuration
- Scopes → openid profile email
- Mapping: Remote ID → sub, Email → email, Verified → email_verified
Azure Active Directory (Entra ID)
- Azure Portal → App registrations → New registration.
- Add TWIM CRM Redirect URI.
- Copy Application (Client) ID → TWIM CRM Client ID.
- Create Client Secret → TWIM CRM Secret.
- Copy OpenID metadata document URL from Endpoints → TWIM CRM Config field.
- Add permissions: openid, profile, email.
- Mapping: Remote ID → oid, Email → userPrincipalName, Verified → true.
Okta
- Okta Admin → Applications → Create App Integration.
- Select OIDC - OpenID Connect, type = Web Application.
- Add TWIM CRM Redirect URL under Login redirect URIs.
- Copy Client ID and Secret → TWIM CRM.
Use Okta metadata URL: https://<okta-domain>/.well-known/openid-configuration- Assign groups/users.
- Mapping: Remote ID → sub, Email → email, Verified → email_verified
Current Limitations & Troubleshooting Common Errors
Currently supports login only. New users cannot sign up with SSO — they must already exist in TWIM CRM.
| Error Message | Cause | How to Fix |
| “Something went wrong, please try again.” | TWIM CRM couldn’t fetch user details from your IdP. May be incorrect endpoints or temporary IdP downtime. | Verify OIDC Config URL/endpoints, confirm IdP app is active, retry later. |
| “Email is not verified, please contact your admin.” | The email_verified attribute is missing or false. | Ensure your IdP includes email_verified = true in the ID token. |
| “remoteIdField is not configured properly, please contact your admin.” | The Remote ID (e.g. sub, oid) is missing or unmapped. | Update your config with a valid unique identifier field. |
| “emailField or idField is not configured properly, please contact your admin.” | Either Email or ID Field mapping is invalid. | Provide a valid Email Field (e.g. email, userPrincipalName) or ID Field. |
| “No user found with this email.” | The IdP user does not exist in TWIM CRM. | Make sure the user exists within TWIM CRM and that you have added externalUserId for the existing users. |
| “You are not authorized to access this account. Please contact your admin.” | The user is missing a valid sub-account association. | Ensure the user is linked to a subaccount in TWIM CRM. |
| “Failed to initiate SSO test.” | The backend could not start the test flow. | Retry. If it persists, email support with your relationship number. |
Add users from the SSO identity provider’s (IDP) user database to GHL
SSO in TWIM CRM currently supports login only — it does not automatically create new users. To ensure your users can log in via SSO, you’ll need to add them to TWIM CRM before they attempt to sign in.
Steps to add users
-
Create a Private Integration Token with the Create or Edit Users scope enabled.
-
Use the Create Users API or Update Users API for SSO to add or update users in TWIM CRM.
-
When creating users, set the parameter externalUserId to match the user’s unique ID from your IdP.
Why this matters
- TWIM CRM matches users based on their externalUserId (Remote ID).
- If a user’s email changes in your IdP, but not in TWIM CRM, login may fail because the system won’t find a matching email.
- However, if externalUserId (or SSO Remote ID) is configured, TWIM CRM will still recognize the user and automatically update their email the next time they log in.
Behind the scenes (for context): When a user logs in via SSO:
- TWIM CRM first looks for a user with a matching SSO Remote ID.
- If none is found, it searches by email + company ID.
- If still not found, login fails.
Mandatory Fields
- Client ID: Tells TWIM CRM which app in your IdP to connect to.
- Secret: Confirms that requests to your IdP are coming from TWIM CRM.
- Auth Method (OIDC): Authentication protocol (locked to OIDC).
1. OIDC Configuration
-
OpenID Config URL: Supplies all endpoints automatically.
-
Authorization URL / Token Endpoint / User Info Endpoint: Manual entry option.
-
Scopes: At minimum openid; recommended openid profile email.
-
Redirect URL:
- Normally prefilled.
If missing: https://<your-whitelabel-domain>/login/sso- Must be whitelisted in IdP. Do not edit unless correcting the format.
2. User Details Mapping
- Remote ID Field: Uniquely identifies the user across both platforms (sub/oid).
- ID Field: Optional — TWIM CRM user ID for direct mapping.
- Email Field: Maps user email from IdP.
- Email Verified Field: Ensures the email is trusted; required for security.
3. Updating User Email in the IdP
- TWIM CRM relies on the externalUserId (Remote ID).
- If a user’s email is updated in the IdP, TWIM CRM will automatically update it on the next login.
Controlling Who Can Configure or Enable SSO
- Current behavior: All agency admins can view, configure, enable, or disable SSO in TWIM CRM.
- Future roadmap: Granular permissions will allow super admins to control which agency admins can manage SSO.
Scopes Explained
Scopes determine what information TWIM CRM can request from your IdP. They are critical for proper user mapping and authentication.
| Scope | What it does | How TWIM CRM uses it | Example |
| openid (mandatory) | Returns the user’s unique identifier (sub). | Links the user to their Remote ID. | Required for all OIDC logins. |
| profile | Returns basic profile info such as name, given_name, family_name. | Can enrich user data in TWIM CRM (e.g. display name). | Helpful if you want names auto-synced, not just email. |
| Returns the user’s email and email_verified flag. | Maps to TWIM CRM’s Email Field and ensures trusted login. | Allows TWIM CRM to automatically update a user’s email if changed in IdP. | |
| groups / roles (provider-dependent) | Returns group/role membership. | Could be used for role-based access or subaccount mapping (future). | If configured in Okta/Azure, lets you enforce “only members of group X can access TWIM CRM.” |
| offline_access (optional) | Returns a refresh token for long-lived sessions. | Not supported in TWIM CRM | Not supported in TWIM CRM |
Frequently Asked Questions
Q: Does TWIM CRM support SAML?
Not yet. The current release supports the OpenID Connect (OIDC) protocol only.
Q: Can I connect more than one IdP to my agency?
Only one active SSO configuration is allowed per agency.
Q: Do users get created automatically the first time they sign in?
No. Create or update users through the Users API and include their externalUserId before they attempt to log in.
Q: What happens if I disable SSO after launch?
Users will fall back to the standard TWIM CRM login page. If you hid other login methods, re-enable them first so users aren’t locked out.
Q: Can I pilot SSO with a handful of users?
Yes. Leave the standard login methods visible and assign externalUserId only to your pilot group; everyone else will continue using email/password.
Q: Will future role-based permissions affect SSO?
Yes—upcoming updates will allow specific admins to manage SSO settings without full agency-owner access, giving you tighter governance.
Q. I Got Redirected to the Login Screen After Starting SSO Test
This is absolutely normal.This happens when the user is visiting the WL domain for the first time and has never logged in before or had logged out from the domain. This will not impact your test status. The test has been executed as it should. If you perform the test again after logging in, you will be able to see the entire flow