Skip to main content

Setting Up SSO (Single Sign-On)

Setting up SSO lets your team access TrustLayer with your existing Identity Provider (IdP). Workspace Owners can now configure SSO directly from Settings → Single Sign-On — no need to contact TrustLayer.

Introduction

Setting up SSO lets your team access TrustLayer with your existing Identity Provider (IDP). Here’s what you’ll need to do and the information you need to provide.

Step 1: Confirm Your IDP & Protocol

TrustLayer supports these IDPs and protocols:

  • OIDC: Okta, Microsoft, Google

  • SAML: Okta, Microsoft, Google

Step 2: Create the TrustLayer app in your IdP

Configure a new application in your identity provider using TrustLayer's service-provider details:

Field

Value

ACS URL / Redirect URL / Reply URL

https://auth.trustlayer.io/__/auth/handler

Entity ID / Audience URI (SAML)

trustlayer.io

Grant type (OIDC)

Implicit Flow (id_token)

NameID format (SAML)

EmailAddress

Also map the attributes (SAML) or claims (OIDC) firstName and lastName so we can display your users' names correctly.

Provider-specific walkthroughs:

Step 3: Gather the required information from your IdP

For SAML:

  • Entity ID (sometimes called Issuer) of your IdP

  • SSO URL (sometimes called Login URL)

  • X.509 Certificate (PEM / Base64)

For OIDC:

  • Client ID

  • Issuer URL

Step 4: Create the configuration in TrustLayer

  1. In TrustLayer, go to Settings → Single Sign-On (visible to workspace Owners).

  2. Click Create configuration.

  3. Choose SAML 2.0 or OIDC and fill in the values gathered in Step 3. You can optionally set a display name that your members will see when they sign in.

  4. Enter the email domain(s) you want to use with SSO (e.g. yourcompany.com) and save.

Step 5: Verify your domains

Before a domain can be used with SSO you need to prove that you own it. Verifying a domain does not switch single sign-on on — until you complete Step 6 your team keeps signing in exactly as they do today.

  1. The Single Sign-On page shows a verification value like trustlayer-sso-domain-verification=.... Copy it.

  2. Sign in to your DNS provider (Cloudflare, GoDaddy, Route 53, …) and create a TXT record on the domain: set the record name (host) to @ and paste the verification value as its content.

  3. Back in TrustLayer, click Verify next to the domain. DNS changes can take up to 48 hours to propagate, so if verification fails, retry later.

Step 6: Turn on single sign-on

Verified domains stay dormant until you switch single sign-on on. That extra step is deliberate: it lets you finish and double-check your identity provider configuration without locking anyone out in the meantime.

  1. On the Single Sign-On page, find the Activation card and click Turn on single sign-on. The button stays disabled until at least one domain is verified.

  2. From that moment, every member whose email is on an activated domain signs in through your identity provider.

If you verify another domain later — a second brand, a regional domain — it is not federated automatically. The Activation card lists it under Verified but not federating logins yet, with an Activate verified domains button. Click it to bring the new domain into single sign-on.

Step 7: You're done

A few things to know:

  • Users are created automatically on their first SSO login (no pre-provisioning needed) with the Team Member role; admins can elevate roles afterwards inside TrustLayer.

  • Sign-in always starts from the TrustLayer login page (SP-initiated); IdP-initiated login is not supported.

  • Once single sign-on is on, members whose email is not on one of your activated domains can no longer sign in with a password. They will see the error “Your email domain is not allowed to access this workspace. Please contact your organization administrator. (ERR012)”. If some of your members should keep password access, see the last section.

  • If your identity provider turns out to be misconfigured and your team cannot sign in, contact our support team — we can switch single sign-on off for your workspace so everyone falls back to password login.

Turning single sign-on off

Workspace Owners can switch single sign-on off at any time from Settings → Single Sign-On with Turn off single sign-on. What happens:

  • Signing in through your identity provider stops immediately, and members sign in with a password again.

  • Anyone whose account was created through single sign-on has never set a password, so they need to use Forgot password? on the login page before they can get back in.

  • Your provider, its settings and your verified domains are kept, so you can switch single sign-on back on later without verifying DNS again.

  • If a sign-in coming from your identity provider reaches TrustLayer while single sign-on is off, it is refused with “Single sign-on is not enabled for this organization. Sign in with your email and password instead, or contact your organization administrator. (ERR013)”.

Optional: Allow password login for external domains

If your workspace has existing members whose email is outside your company domains — for example external consultants or partner agencies — you can allow their email domains to keep signing in with a password while everyone else uses SSO:

  1. In TrustLayer, go to Settings → Single Sign-On. Workspace Owners and Admins can manage this list.

  2. In the External login domains card, enter the domain (e.g. partner.com) and click Add domain.

  3. To revoke password access later, click Remove next to the domain.

A few important notes:

  • This does not invite or add anyone — it only changes how existing members on those domains sign in.

  • Security: members on a listed domain bypass your identity provider entirely, so every domain you add weakens your SSO guarantee. Keep the list as narrow as possible, and never add public email domains such as gmail.com.

Did this answer your question?