SSO / OIDC configuration
See which sign-in providers OmniLab supports and what to share with your Customer Success Manager to enable each one.
In this article, you'll see which sign-in providers OmniLab currently supports, what information your team must prepare for each one, and how to test the sign-in flow once your Customer Success Manager enables it.
Prerequisites
- You know which sign-in provider your organisation wants to use.
- You have an IT contact who can create or update the application in that provider.
- The target users already exist in OmniLab or will be created before testing.
- Each test user will be assigned to at least one organisation in OmniLab.
SSO is enabled per OmniLab environment
Customers do not self-configure SSO in the current flow. Your Customer Success Manager coordinates the setup, provides the exact OmniLab callback URL to register in your provider, and enables the provider for your OmniLab environment.
Enable a provider
Choose the provider you want to use
Confirm whether you want Microsoft Entra ID, Salesforce Marketing Cloud, or a custom enterprise SSO provider with its own sign-in button label.
Prepare the provider details with your IT team
Create or update the application in your identity provider, then gather the IDs, secrets, URLs, and any scope details OmniLab needs for that provider.
Share the configuration details with your Customer Success Manager
Send the provider details to your Customer Success Manager so OmniLab can enable the provider for your environment and connect it to the correct OmniLab setup.
Create or verify your OmniLab users
Before testing, make sure each user already exists in OmniLab and is assigned to at least one organisation. Sign-in succeeds only for users whose account already exists in OmniLab.
Test the sign-in flow
Open your OmniLab sign-in page, choose the enabled provider button, complete authentication with the provider, and confirm that OmniLab opens with the expected organisation access.
Supported sign-in providers
Users only see the providers enabled for their OmniLab environment.
| Provider | What users typically see | Current notes |
|---|---|---|
| Microsoft Entra ID | A Microsoft button, or your configured display name | Best fit when your organisation already uses Microsoft identity |
| Salesforce Marketing Cloud | Salesforce Marketing Cloud | Uses provider-specific OAuth endpoints |
| Custom enterprise SSO provider | Your configured display name | Useful when you want a branded enterprise sign-in button |
If you need a provider that is not listed here, confirm availability with your Customer Success Manager before planning your rollout.
Information to share for each provider
Microsoft Entra ID
Share these items with your Customer Success Manager:
| Required information | Why OmniLab needs it |
|---|---|
| Application (client) ID | Identifies your Entra app |
| Directory (tenant) ID | Connects OmniLab to the correct Microsoft tenant |
| Client secret | Lets OmniLab complete the secure sign-in flow |
| Desired button label, if you do not want the default Microsoft label | Controls what users see on the sign-in page |
| Confirmation that the exact OmniLab callback URL has been registered in Entra ID | The Microsoft app must trust OmniLab's callback URL |
For Entra ID and other OpenID Connect-style setups, expect the standard scopes openid, email, and profile.
Salesforce Marketing Cloud
Share these items with your Customer Success Manager:
| Required information | Why OmniLab needs it |
|---|---|
| Client ID | Identifies your Salesforce Marketing Cloud app |
| Client secret | Lets OmniLab complete the secure sign-in flow |
| Authorization URL | Starts the sign-in flow |
| Token URL | Lets OmniLab exchange the authorization result for tokens |
| User info URL | Lets OmniLab read the signed-in user's identity |
| Confirmation that the exact OmniLab callback URL has been registered | The connected app must trust OmniLab's callback URL |
Custom enterprise SSO provider
Share these items with your Customer Success Manager:
| Required information | Why OmniLab needs it |
|---|---|
| Display name for the sign-in button | Controls what users see on the OmniLab sign-in page |
| Client ID | Identifies your provider app |
| Client secret | Lets OmniLab complete the secure sign-in flow |
| Authorization URL | Starts the sign-in flow |
| Token URL | Lets OmniLab exchange the authorization result for tokens |
| User info URL | Lets OmniLab read the signed-in user's identity |
| Scope string, if your provider requires one | Lets OmniLab request the correct identity data |
| Confirmation that the exact OmniLab callback URL has been registered | Your provider must trust OmniLab's callback URL |
If your provider follows OpenID Connect conventions, the scope string is usually based on openid, email, and profile.
Temporary fallback during rollout
If you want a safer rollout, ask whether Continue with Email should stay enabled while SSO is being tested. OmniLab currently supports email magic-link sign-in as a separate option.
Before you test sign-in
Check these items before you ask users to test:
| Check | Why it matters |
|---|---|
| The provider is enabled for the correct OmniLab environment | Users only see providers enabled for their OmniLab environment |
| The OmniLab callback URL is registered in the provider | The sign-in flow cannot complete without it |
| The user already exists in OmniLab | OmniLab checks that the user account already exists |
| The user is assigned to at least one organisation | OmniLab needs organisation access to finish sign-in cleanly |
| The user signs in with the same email address that exists in OmniLab | OmniLab matches sign-in access to the existing user account |