Getting Started

Configuring Single Sign-On (SSO)

Single Sign-On lets people reach Tidal Control with your organisation's existing login, over OIDC. You configure an application in your identity provider, hand the credentials to Tidal, and we complete the connection at our end. This article covers all five supported providers.

Supported identity providers

Tidal Control supports SSO via the OIDC (OpenID Connect) protocol with:

  • Microsoft Azure/Entra ID - For Microsoft 365 organisations
  • Google Workspace - For Google-based organisations
  • Okta - Enterprise identity management platform
  • Auth0 - Flexible authentication service
  • OneLogin - Cloud-based identity provider
  • Other OIDC providers - Any system supporting OIDC

Preparation

Before touching your identity provider, collect the redirect details from Tidal and check you have the admin rights to register an application.

Required information

Some of this comes from Tidal, some from your identity provider once you've configured it there.

Needed from Tidal Control:

  • Tenant name - Found in your login URL: https://portal.tidalcontrol.com/{TENANT_NAME}/
  • Redirect URI - Automatically becomes: https://auth.tidalcontrol.com/realms/{TENANT_NAME}/broker/oidc/endpoint

Needed from your identity provider (after configuration):

  • Client ID - Unique identifier for Tidal application
  • Client Secret - Secret key for authentication
  • Tenant/Domain ID - Your organisation identifier (name varies per provider)

Required permissions

You need administrator rights in your identity provider to:

  • Create new application registrations
  • Generate client secrets
  • Assign user groups

Microsoft Azure/Entra ID

In Entra ID you register an application and come away with three values: the tenant ID, the client ID, and a client secret.

Finding Tenant ID

The fastest way is through the Azure Portal itself; the OpenID endpoint works too if you don't have portal access.

Via Azure Portal:

  1. Log in to Azure Portal
  2. Navigate to "Microsoft Entra ID" (formerly Azure Active Directory)
  3. Copy Tenant ID from overview page

Via OpenID endpoint:

  1. Open browser to: https://login.microsoftonline.com/{YOUR_DOMAIN}/v2.0/.well-known/openid-configuration
  2. Find "issuer" field in JSON response - this contains your Tenant ID

Creating app registration

  1. Go to "App registrations" in Entra ID menu

  2. Click "New registration" at top

  3. Configure basic information:

    • Name: Tidal Control - SSO
    • Supported account types: "Accounts in this organizational directory only (Single tenant)"
    • Redirect URI:
      • Platform: Web
      • URI: https://auth.tidalcontrol.com/realms/{TENANT_NAME}/broker/oidc/endpoint

  4. Click "Register" to create app

Generating client secret

  1. Open your new app registration

  2. Copy these values from overview page:

    • Application (client) ID
    • Directory (tenant) ID

  3. Go to "Certificates & secrets" in left menu

  4. Click "New client secret"

  5. Configure secret:

    • Description: Tidal Control SSO
    • Expires: Choose expiry date (e.g. 24 months)

  6. Click "Add"

  7. Copy secret value immediately (shown only once!)

Warning

Important: Store the client secret securely. You can't retrieve this value later. You'll need to create a new one if you lose it.

Configuring API permissions (optional)

No extra permissions needed for basic SSO. For advanced integration:

  1. Go to "API permissions"
  2. Click "Add a permission"
  3. Select "Microsoft Graph"
  4. Choose "Delegated permissions"
  5. Select minimum:
    • openid - For authentication
    • profile - For user data
    • email - For email address

Google Workspace

Google requires a consent screen configured before you can create the OAuth client itself.

Creating OAuth 2.0 Client

  1. Go to Google Cloud Console
  2. Select project or create new one
  3. Navigate to "APIs & Services" → "Credentials"

Configuring OAuth consent screen

  1. Click "Configure consent screen" if not done yet
  2. Choose "Internal" for organisation users only
  3. Fill in app information:
    • App name: Tidal Control
    • User support email: Your support email
    • Authorised domains: tidalcontrol.com
  4. Add scopes:
    • openid
    • email
    • profile
  5. Save and continue

Creating Client ID

  1. Click "Create credentials" → "OAuth client ID"
  2. Configure client:
    • Application type: Web application
    • Name: Tidal Control SSO
    • Authorised redirect URIs: https://auth.tidalcontrol.com/realms/{TENANT_NAME}/broker/oidc/endpoint
  3. Click "Create"
  4. Copy credentials:
    • Client ID
    • Client secret

Okta

Okta gives you three values to copy, not two: client ID, client secret, and your Okta domain.

Adding new application

  1. Log in to your Okta Admin Console
  2. Go to "Applications" → "Applications"
  3. Click "Create App Integration"

Configuring OIDC

  1. Select integration type:

    • Sign-in method: OIDC - OpenID Connect
    • Application type: Web Application

  2. Click "Next"

  3. Configure application settings:

    • App name: Tidal Control
    • Sign-in redirect URIs: https://auth.tidalcontrol.com/realms/{TENANT_NAME}/broker/oidc/endpoint
    • Sign-out redirect URIs: https://portal.tidalcontrol.com/{TENANT_NAME}/

  4. Configure assignments:

    • Controlled access: Choose which groups get access
    • Or select "Allow everyone in your organisation to access"

  5. Click "Save"

Retrieving credentials

  1. Open your new application
  2. Go to "General" tab
  3. Copy from "Client Credentials" section:
    • Client ID
    • Client secret
  4. Copy Okta domain from your account URL (e.g.: dev-12345.okta.com)

Auth0

Auth0 also gives you a domain value, and lets you manage who gets access from the same dashboard.

Creating application

  1. Log in to Auth0 Dashboard
  2. Go to "Applications" → "Applications"
  3. Click "Create Application"

Configuring application

  1. Configure basic settings:

    • Name: Tidal Control
    • Application type: Regular Web Applications

  2. Click "Create"

  3. Go to "Settings" tab

  4. Configure URLs:

    • Allowed Callback URLs: https://auth.tidalcontrol.com/realms/{TENANT_NAME}/broker/oidc/endpoint
    • Allowed Logout URLs: https://portal.tidalcontrol.com/{TENANT_NAME}/
    • Allowed Web Origins: https://portal.tidalcontrol.com

  5. Copy credentials:

    • Domain (e.g.: your-tenant.auth0.com)
    • Client ID
    • Client Secret

  6. Click "Save Changes"

Assigning users

  1. Go to "User Management" → "Users"
  2. Add users who need access
  3. Or configure "Connections" for automatic user provisioning

OneLogin

OneLogin's setup starts from a pre-built catalogue entry rather than a blank application.

Adding app from catalogue

  1. Log in to OneLogin Admin Portal
  2. Go to "Applications" → "Applications"
  3. Click "Add App"
  4. Search "OpenID Connect" in catalogue
  5. Select "OpenId Connect (OIDC)" app

Configuring OIDC app

  1. Configure display name:

    • Display Name: Tidal Control
    • Click "Save"

  2. Go to "Configuration" tab

  3. Fill in redirect URI:

    • Redirect URI: https://auth.tidalcontrol.com/realms/{TENANT_NAME}/broker/oidc/endpoint
    • Click "Save"

  4. Go to "SSO" tab

  5. Copy credentials:

    • Client ID
    • Client Secret
    • Issuer URL (use as Domain/Tenant ID)

Giving users access

  1. Go to "Users" tab in the app
  2. Click "Add users"
  3. Select users or groups
  4. Click "Save"

Sending configuration to Tidal

Tidal completes the connection at our end, so the last step is handing over the credentials securely and waiting for activation.

Securely sharing credentials

After configuration in your identity provider, send the following information securely to Tidal Control:

Collect this information:

Identity Provider: [Azure/Google/Okta/Auth0/OneLogin]
Tenant/Domain: [Your organisation domain/tenant ID]
Client ID: [Application/Client ID]
Client Secret: [Secret key]

Secure sending methods:

  • Encrypted ZIP file with password (send password separately)
  • Password manager with secure sharing function (1Password, Bitwarden)
  • Secure messaging service (Signal, encrypted email)
  • Temporary secret sharing service (e.g. PrivateBin with expiry)
Danger

Never do:

  • Send client secrets via ordinary email
  • Place credentials in chat applications
  • Take screenshots of secrets
  • Store secrets in tickets or documentation

Contact Tidal Support

Email to: support@tidalcontrol.com

Subject: SSO Configuration for [TENANT_NAME]

Email content:

Dear Tidal Support,

We would like to activate SSO for our Tidal environment.

Tenant name: [TENANT_NAME]
Identity Provider: [PROVIDER_NAME]

I'll send the configuration details via [METHOD].

Kind regards,
[Name]

Activation timeline

Tidal configures the connection within one working day, then you test it before it goes live for everyone.

After receiving credentials:

  1. Tidal configures SSO connection (within 1 working day)
  2. Test account is created for verification
  3. You test the connection with test user
  4. After successful test SSO is activated for all users
  5. Existing users can log in with SSO

Using SSO after activation

Once SSO is live, users sign in through your identity provider instead of with a Tidal password.

First time logging in

A new user's account is created automatically the first time they sign in through SSO.

For new users:

  1. Go to https://portal.tidalcontrol.com/{TENANT_NAME}/
  2. Click "Sign in with SSO" button
  3. Log in with your organisation account
  4. Account is automatically created in Tidal

For existing users:

  1. Use same email as in Tidal account
  2. SSO automatically links to existing account
  3. Access rights remain preserved

Multi-factor authentication (MFA)

With SSO in place, configure MFA in your identity provider rather than in Tidal, so one policy covers every application.

MFA via identity provider

Best practice: Configure MFA in your identity provider, not in Tidal:

  • Central MFA policy for all applications
  • Conditional access based on location/device
  • Compliance reporting from one system

MFA configuration per provider:

  • Azure: Conditional Access Policies
  • Google: 2-Step Verification enforcement
  • Okta: Authentication Policies
  • Auth0: Multi-factor Authentication rules
  • OneLogin: Authentication Factors policies

User synchronisation (optional)

SSO handles authentication but not account creation. SCIM provisioning is what keeps the user list in step automatically.

Automatic provisioning

For large organisations, automatic user synchronisation via SCIM:

  • Automatically create new users
  • Role assignment based on groups
  • Deactivation when employee leaves

SCIM support varies per provider:

  • Azure/Entra ID ✅
  • Okta ✅
  • OneLogin ✅
  • Google Workspace ⚠️ (via third-party)
  • Auth0 ⚠️ (custom implementation)

Contact support@tidalcontrol.com for SCIM configuration.

Why use SSO?

Single Sign-On offers important advantages for compliance organisations:

  • Central access control - Manage all user access from one system
  • Automatic deactivation - When employees leave, access is revoked everywhere
  • User convenience - Teams don't need to remember separate password for Tidal
  • Enforce security policies - Multi-factor authentication (MFA) and password policy via your identity provider

Troubleshooting

Three failures account for nearly every SSO problem: a redirect loop, an access-denied after a successful login, and an expired client secret.

Login redirect loop

Symptoms: Browser keeps redirecting between Tidal and identity provider

Solutions:

  1. Check redirect URI - Must match exactly
  2. Clear browser cookies for both domains
  3. Test incognito/private browsing mode
  4. Verify tenant name in URI configuration

"Access Denied" after successful authentication

This almost always means the user or their group isn't actually assigned to the application in your identity provider.

Possible causes:

  • User not assigned to application in identity provider
  • Group membership not correctly configured
  • Email address doesn't match Tidal account

Verification steps:

  1. Check user assignment in identity provider
  2. Compare email addresses between systems
  3. Test with new test user

Client secret expired

Symptoms: SSO suddenly stops working for all users

Solution:

  1. Generate new secret in identity provider
  2. Send to Tidal Support via secure method
  3. Temporary workaround: Users can request password reset

For further support, email support@tidalcontrol.com with:

  • Tenant name
  • Identity provider type
  • Exact error message
  • Browser console errors (F12)
Next
Implementing a framework with a template