Single Sign-On (SSO) with Entra ID & Okta

Overview

SecuriTLS supports Single Sign-On through Microsoft Entra ID and Okta using OpenID Connect (OIDC).

SSO allows users to authenticate with your organization's existing identity provider instead of using a SecuriTLS password.

Each SSO configuration is associated with a verified login domain. When a user selects Sign in with SSO, SecuriTLS uses the domain portion of the user's email address to locate the appropriate SSO configuration.

Team plan or higher

Single Sign-On is available on Team, Business, and Enterprise subscriptions.

Supported identity providers

SecuriTLS currently supports:

Microsoft Entra ID
Okta

Authentication takes place directly with the configured identity provider. SecuriTLS validates the resulting OIDC response before granting access to the workspace.

SSO login workflow

A typical SSO login follows this process:

The user selects Sign in with SSO from the SecuriTLS login page.
The user enters their email address.
SecuriTLS extracts the domain from the email address.
SecuriTLS locates a verified domain with an enabled SSO configuration.
The user is redirected to Microsoft Entra ID or Okta.
The identity provider authenticates the user according to the organization's authentication policies.
The provider redirects the user back to the SecuriTLS OIDC callback.
SecuriTLS validates the returned authorization response and ID token.
The external identity is matched to an authorized SecuriTLS user mapping.
If the identity is authorized, SecuriTLS creates the authenticated workspace session.

Configure SSO

SSO is configured from the Security page in SecuriTLS.

Open the Security page.
Add and verify the domain that will be used for SSO login.
Select Microsoft Entra ID or Okta.
Enter the identity provider configuration.
Add the external identities that are permitted to access SecuriTLS.
Assign a SecuriTLS role to each external identity.
Save the configuration.
Use Test SSO to validate the saved configuration.
Enable Single Sign-On when the configuration is ready for normal login.

Verify a login domain

SecuriTLS requires proof of domain ownership before a domain can be used for SSO discovery.

From the Security page, click Manage beside the Login Domain field and add the domain you want to use.

SecuriTLS generates a DNS TXT record similar to:

Type
TXT

Host
_securitls-verification.example.com

Value
securitls-domain-verification=<verification-token>

Add the TXT record through your DNS provider, then click Verify Domain in SecuriTLS.

After verification succeeds, the domain becomes available in the SSO Login Domain selector.

DNS propagation may take time

If the TXT record was recently created, verification may fail until the record becomes visible through DNS resolvers. Wait for DNS propagation and try again.

Microsoft Entra ID

A Microsoft Entra ID configuration requires:

Tenant ID
Client ID
Client Secret

Redirect URI

Configure the following redirect URI in the Microsoft Entra application:

https://www.securitls.com/sso/entra/callback

The redirect URI configured in Entra must exactly match the SecuriTLS callback URI.

OIDC scopes

SecuriTLS requests:

openid profile email

User identity

SecuriTLS maps Microsoft Entra users using the stable oid claim.

Add the Entra Object ID for each user who should have access to the SecuriTLS workspace and assign the appropriate SecuriTLS role.

Use the Entra Object ID

The authorized-user mapping uses the Entra oid value rather than the user's email address.

Okta

An Okta configuration requires:

Okta Domain
Client ID
Client Secret

The Okta domain typically looks similar to:

https://your-company.okta.com

Redirect URI

Configure the following sign-in redirect URI in your Okta application:

https://www.securitls.com/sso/okta/callback

OIDC scopes

SecuriTLS requests:

openid profile email

User identity

SecuriTLS maps Okta users using the stable OIDC sub claim.

Add the user's Okta subject identifier to the Authorized Users section and assign the appropriate SecuriTLS role.

Authorized users and roles

Successfully authenticating with the identity provider does not automatically grant access to the SecuriTLS workspace.

The external identity must also exist in the SSO configuration's Authorized Users list.

Each identity is assigned a SecuriTLS role:

Admin — administrative access to the workspace and its configuration.
Operator — operational access according to the permissions assigned to the Operator role.
Viewer — read-oriented access according to the permissions assigned to the Viewer role.

Provider	Identity claim
Microsoft Entra ID	`oid`
Okta	`sub`

Test SSO

SecuriTLS allows you to test a saved SSO configuration before relying on it for normal authentication.

Click Test SSO on the Security page to perform the actual OIDC authentication flow against the saved identity provider configuration.

The test exercises:

Identity provider redirect
Authorization code exchange
ID token validation
Issuer and audience validation
Nonce validation
External identity mapping
Workspace ownership validation

Test SSO uses the saved configuration

Unsaved changes on the Security page must be saved or reset before testing.

An SSO configuration can be tested while it is disabled. This allows the integration to be validated before enabling SSO for normal users.

A successful SSO test returns the administrator to the Security page and does not replace the current SecuriTLS login session.

Enable or disable SSO

The Enable Single Sign-On setting controls whether the SSO configuration participates in normal login discovery.

When the configuration is disabled:

The SSO configuration remains stored.
Normal SSO login through that configuration is unavailable.
The configuration can still be tested from the Security page.

This allows an administrator to temporarily disable SSO without deleting the identity provider configuration.

SSO and multi-factor authentication

SecuriTLS does not apply its local authenticator 2FA challenge after a successful SSO authentication.

Multi-factor authentication for SSO users is controlled by the external identity provider.

Microsoft Entra ID and Okta can enforce MFA, passkeys, hardware security keys, and other authentication requirements before returning an authenticated identity to SecuriTLS.

SecuriTLS authenticator-based two-factor authentication applies to local password-based authentication.

Security model

SecuriTLS validates the OIDC authentication result before creating a workspace session.

Validation includes:

Authorization state validation
OIDC nonce validation
ID token signature validation
Issuer validation
Audience validation
Configured provider validation
External identity authorization
Workspace ownership validation
Email consistency during normal SSO login

Client secrets stored by SecuriTLS are encrypted and are not returned to the browser after they have been saved.

Login preference

The SecuriTLS login page supports both normal authentication and SSO.

After a successful SSO login, SecuriTLS can remember SSO as the preferred login experience for that browser.

The preference only determines which login interface is shown first. It does not grant SSO access or bypass domain discovery, identity provider authentication, or user authorization.

Audit events

Security-sensitive SSO operations are recorded in the SecuriTLS audit history.

Audit events can include:

SSO configuration created
SSO configuration updated
SSO enabled
SSO disabled
SSO configuration deleted
Login domain added
Login domain verified
SSO test initiated
SSO test succeeded
SSO test failed

Sensitive authentication material such as client secrets, authorization codes, ID tokens, nonces, and access tokens is not included in audit records.

Configuration reference

Setting	Description
Identity Provider	Microsoft Entra ID or Okta.
Login Domain	Verified domain used to discover the SSO configuration from the user's email address.
Tenant ID	Microsoft Entra tenant identifier. Used for Entra configurations only.
Okta Domain	Okta issuer URL, such as `https://your-company.okta.com`.
Client ID	OIDC client identifier issued by the identity provider.
Client Secret	Secret associated with the OIDC application. The saved secret is not displayed again.
Authorized Users	External identities permitted to access the SecuriTLS workspace.
Role	SecuriTLS workspace role assigned to the external identity.
Enable Single Sign-On	Controls whether the configuration is available for normal SSO login.

Troubleshooting

SSO configuration is not found

Confirm the user's email domain matches the configured Login Domain.
Confirm the domain has been successfully verified.
Confirm the SSO configuration is enabled.

The identity provider rejects the redirect URI

Confirm that the configured redirect URI exactly matches the appropriate SecuriTLS callback.

Microsoft Entra ID
https://www.securitls.com/sso/entra/callback

Okta
https://www.securitls.com/sso/okta/callback

Authentication succeeds at the provider but SecuriTLS rejects the login

Confirm that the authenticated identity appears in the Authorized Users section.

For Microsoft Entra ID, verify the configured oid.
For Okta, verify the configured sub.

Domain verification fails

Confirm the TXT record exists at the exact host shown by SecuriTLS.
Confirm the TXT value exactly matches the value generated by SecuriTLS.
Allow time for DNS changes and cached negative DNS results to expire.

Test SSO is disabled

Test SSO operates against the saved configuration. Save or reset any unsaved changes before running the test.

Test SSO fails after identity provider login

Confirm the Client ID and Client Secret are correct.
Confirm the Tenant ID or Okta Domain is correct.
Confirm the authenticated user is listed under Authorized Users.
Confirm the configured external identity matches the provider's oid or sub value.