Skip to content
Thirdlane

Identity Providers

As an alternative to logging into Thirdlane Connect and the Configuration Manager using a username and password, users can authenticate using external identity providers via the OIDC (OpenID Connect) standard.

Navigate to General Settings & Tools > Identity Providers to configure one or more identity providers.

Supported Providers

ProviderTypeNotes
GoogleNativeAccess to Google contacts via scopes
MicrosoftNativeAccess to Microsoft contacts via scopes
OktaNative + OIDCUses Okta-specific discovery; also works via generic OIDC
Microsoft Entra IDOIDCStandard OIDC discovery with your tenant ID
Google WorkspaceOIDCStandard OIDC discovery via accounts.google.com
Auth0OIDCStandard OIDC discovery with your Auth0 domain
KeycloakOIDCStandard OIDC discovery with your realm URL
Authentik (OIDC)OIDCSelf-hosted identity provider, standard OIDC
ZohoNativeUses Zoho-specific endpoints
Generic OIDCOIDCAny OIDC-compliant identity provider

Providers marked OIDC all use the same protocol under the hood: they connect to your identity provider’s /.well-known/openid-configuration endpoint to automatically discover authorization, token, and userinfo URLs. The named entries (Entra ID, Auth0, etc.) are convenience labels — they use the same OIDC mechanism as the generic option.

Adding a Provider

  1. Click Add
  2. Select the provider type from the dropdown
  3. Fill in:
    • Client ID and Client Secret — obtained from your identity provider’s developer console
    • Issuer URL (for OIDC-based providers) — the base URL of your IdP
    • Button Label (optional) — custom text for the SSO login button
  4. Click Save
  5. Copy the displayed Redirect URIs and register them in your identity provider’s allowed callback URLs

Redirect URIs

After saving, two redirect URIs are shown:

  • Config Manager Redirect URI — for admin SSO login to the Configuration Manager
  • Connect Redirect URI — for user SSO login to Thirdlane Connect

Both must be registered as allowed redirect/callback URLs in your identity provider.

Provider Setup Guides

Google

  1. Go to Google Cloud Console > APIs & Services > Credentials
  2. Create an OAuth 2.0 Client ID (Web application type)
  3. Add both redirect URIs to Authorized redirect URIs
  4. Enable the People API if you want contact access
  5. Copy the Client ID and Client Secret to the Authentication Providers form
  6. Select Google as the provider (no Issuer URL needed)

Microsoft / Entra ID

  1. Go to Azure Portal > App registrations > New registration
  2. Set redirect URIs (Web platform) to both callback URLs
  3. Under Certificates & secrets, create a new client secret
  4. Copy Application (client) ID and the secret value
  5. For Microsoft (native): select Microsoft as provider, no Issuer URL needed
  6. For Microsoft Entra ID (OIDC): select Microsoft Entra ID, set Issuer URL to https://login.microsoftonline.com/{your-tenant-id}/v2.0

Okta

  1. In the Okta Admin Console, go to Applications > Create App Integration
  2. Select OIDC - OpenID Connect, then Web Application
  3. Add both redirect URIs
  4. Copy the Client ID and Client Secret
  5. Select Okta as provider, set Issuer URL to https://your-org.okta.com

Authentik

  1. In Authentik Admin, create a new OAuth2/OIDC Provider
  2. Set the redirect URIs to both callback URLs
  3. Set Client Type to Confidential
  4. Copy the Client ID and Client Secret
  5. Select Authentik (OIDC) as provider
  6. Set Issuer URL to https://your-server/application/o/your-app/

For a complete walkthrough including MFA configuration, see SSO and MFA.

Generic OIDC

For any other OIDC-compliant provider (OneLogin, PingIdentity, Duo, etc.):

  1. Create an OIDC/OAuth2 application in your provider
  2. Set both redirect URIs
  3. Select Generic OIDC as provider
  4. Enter the Issuer URL (the base URL your provider uses for OIDC discovery)

Worked example: let admins sign in to Configuration Manager with Okta

Goal: your administrators log into the Configuration Manager with their existing Okta accounts, while username/password stays as a fallback.

  1. Create the Okta app. In the Okta Admin Console, Applications > Create App Integration > OIDC - OpenID Connect > Web Application. Leave the redirect URIs blank for a moment (you get the exact values from Thirdlane in step 3). Copy the Client ID and Client Secret.
  2. Add the provider in Thirdlane. Under General Settings & Tools > Identity Providers, click Add, select Okta, paste the Client ID and Client Secret, set Issuer URL to https://your-org.okta.com, and set Button Label to Company SSO. Save.
  3. Register the redirect URIs. Thirdlane now shows two URIs - Config Manager Redirect URI and Connect Redirect URI. Paste both into the Okta app’s Sign-in redirect URIs (even if you only care about admin login today, registering both avoids a later surprise).
  4. Make sure a matching admin exists. SSO does not create accounts - it matches the Okta email to an existing admin username/email. Confirm each admin’s Administrator record uses the same email as Okta.
  5. Test. Open the Configuration Manager login page; a Company SSO button now appears under the password form. Click it, authenticate with Okta (completing any MFA Okta enforces), and you are redirected back logged in. If you instead land back on the login page, the Okta email had no matching admin (step 4); if you get a redirect-URI error, step 3 is incomplete.

For a provider that also enforces MFA and covers Connect users, see the SSO and MFA walkthrough.

User Mapping

When a user authenticates via SSO, the system matches their identity provider email address to an existing account:

  • Configuration Manager: matches against admin usernames and email addresses
  • Thirdlane Connect: matches against user extension names and email addresses

Users must have pre-existing accounts. SSO does not automatically create new accounts.

Directory Services vs SSO

These are related but distinct features:

  • Directory Services (under Organization Settings > Integrations) sync user accounts from Microsoft/Okta/LDAP into the PBX. This is about provisioning — creating and updating user records.
  • Authentication Providers (this page) enable SSO login. This is about authentication — how users prove their identity.

You can use both together: Directory Services to automatically create user accounts from your corporate directory, and Authentication Providers to let those users log in with their corporate credentials via SSO.

Troubleshooting

IssueSolution
SSO button not visibleVerify provider is configured and saved in Authentication Providers
”Invalid or expired state”Login took too long (>10 min). Try again.
Redirect back to login after SSONo matching PBX user found for the IdP email. Create a user with matching username or email.
Connect OIDC button missingCheck that /oauth2/providers returns the provider in the list
”Provider error” on callbackVerify Client ID, Client Secret, and Issuer URL are correct
Wrong redirect URI errorEnsure both redirect URIs shown after saving are registered in your IdP
Token exchange failsCheck that the Client Secret has not expired (common with Azure AD)