Skip to main content
Single sign-on (SSO) lets your team sign in to CloudThinker through your company identity provider (IdP), such as Okta, Microsoft Entra ID or Google Workspace, so you manage access in one place. This page takes you from an unverified domain to a working, enforced SSO connection.

​
Prerequisites

  • An organization on the Scale, Scale Plus or Enterprise plan. On other plans, Admin Settings → Identity and access shows Unlock SSO with the Scale plan and an Upgrade Plan button. See Pricing.
  • The organization Owner role. Only Owners can manage SSO; Admins get a permission error. See Roles and permissions.
  • Access to your DNS provider, to add one TXT record.
  • Admin access to your identity provider.

​
How setup works

Admin Settings → Identity and access shows a Setup progress checklist with three stages. Each one unlocks the next. When all three are done, the checklist collapses into a status bar, for example SSO Active, SAML, 1 verified domain, SSO optional.
Admin Settings, Identity and access page with the setup checklist, Domain management card and Single sign-on card

Identity and access: verify a domain, configure SSO, then choose provisioning

​
Verify your domain

Your domain tells CloudThinker which sign-ins to send to your identity provider. Anyone whose email ends in a verified domain is routed to SSO.
1

Add the domain

Go to Admin Settings → Identity and access. On the Domain management card, click Add domain. Type your email domain (for example, example.com) and click the + button.A domain can belong to only one CloudThinker organization. If another organization already claimed it, you see an error and need to contact that organization’s Owner.
2

Add the DNS TXT record

In the domains table, click Verify next to the domain. The Verify domain dialog shows two values. Create a TXT record at your DNS provider with them:
3

Check verification

Wait for the record to propagate, then click Check verification. Propagation is often a few minutes but can take longer, depending on your DNS provider.Success state: the domain shows Verified in the table, and the Setup SSO button on the Single sign-on card is enabled.CloudThinker checks the record only when you click Check verification. It doesn’t re-check later, so you can delete the TXT record once the domain is verified.
You can verify more than one domain, for example example.com and example.co.uk. While the connection is active, you can’t remove the last verified domain; deactivate the connection first.

​
Create the connection

An organization has one SSO connection, and it serves every verified domain. Pick the protocol your identity provider supports. If it supports both, either works; SAML is the most common choice for enterprise IdPs.
1

Start the wizard

On the Single sign-on card, click Setup SSO. Choose SAML 2.0 or OpenID Connect (OIDC) and click Next.
2

Follow your provider's guide

Open the SAML or OIDC guide above and complete the steps for your provider, then click Create Connection.Success state: the dialog shows SSO Connection Created. The connection is active right away, and sign-in through SSO is available but not yet required.
3

Run the connection test

On the Single sign-on card, click Manage. On the Overview tab, under Connection test, click Run connection test.The test checks your configuration, not a full sign-in. For SAML it checks the IdP Entity ID, SSO URL and certificate. For OIDC it checks that the discovery document is reachable, the issuer matches, the required endpoints exist, and the signing keys are reachable.Success state: All checks passed. If you see Some checks failed, the failing check and an error message are listed; fix the value on the Configuration tab and click Save Changes.
4

Sign in through SSO

In a private browser window, open the CloudThinker sign-in page at https://app.cloudthinker.io/auth/login, enter an email on your verified domain, and click Continue with SSO. You can also click Sign in with SSO and enter your Work email.Success state: your IdP’s sign-in page opens, and after you sign in you land back in CloudThinker with your name shown.
As soon as a connection is active, new people on your verified domain can’t create an account with Google or GitHub sign-in. They’re told “Your organization uses SSO. Please sign in with SSO.” Existing users can still pick Use an email code instead on the SSO screen until you require SSO.People who already have a CloudThinker account keep it. Their first SSO sign-in matches the account by email and links it to your IdP, so no duplicate is created.

​
Choose how users are provisioned

Provisioning is how a CloudThinker account gets created for someone in your company. The Provisioning & directory sync card appears once the connection is active. For Just-in-time and SCIM, also set:
  • Auto-assigned organization role: Viewer (default), Developer or Admin. Start with Viewer and promote people later.
  • Auto-assigned workspaces: the workspaces new users join automatically. The default is your organization’s default workspace. See Workspaces.

​
Require SSO

With SSO optional, people on your domain can still sign in with an email code. Turning on Require SSO removes that option.
1

Confirm SSO works for you

Complete the sign-in test above with your own account first.
2

Turn on Require SSO

On the Single sign-on card, turn on Require SSO.Success state: the status bar shows SSO required. Users on your verified domains must sign in through your identity provider. Other sign-in methods return “Your organization requires SSO. Please sign in with SSO.”
Require SSO is checked at sign-in. It doesn’t sign out anyone who is already signed in; they move to SSO the next time they sign in. The toggle only shows while the connection is Active. Requiring SSO also changes invitations: you can only invite emails on a verified domain. With SCIM selected, manual invitations are turned off, and you manage people in your IdP.

​
If your IdP is unavailable

Each organization has exactly one Owner, and the Owner is exempt from Require SSO, so an IdP outage or an expired certificate doesn’t lock you out. The Owner enters their email on the sign-in page, then picks Use an email code instead on the SSO screen. Everyone else waits until the IdP is back, or until the Owner turns off Require SSO on the Single sign-on card.
Before you turn on Require SSO, make sure the Owner’s email address receives mail outside your IdP, for example a monitored shared mailbox. That inbox is your way back in.

​
Manage or remove the connection

Click Manage on the Single sign-on card. The dialog has two tabs: Delete is permanent and does more than deactivating:
  • Require SSO goes away with the connection, and users fall back to email-code sign-in.
  • SCIM is removed: the token stops working, and group mappings and sync logs are deleted. Turn off provisioning in your IdP too.
  • Member accounts and their roles stay, including people created by just-in-time or SCIM provisioning.
To pause SSO, deactivate instead.

​
Troubleshooting

The card reads “Verify at least one domain before configuring SSO.” Open Verify on the domain and confirm your TXT record name is _cloudthinker and its value matches the Record Value exactly. Some DNS providers add the domain for you, so a name of _cloudthinker.example.com can turn into _cloudthinker.example.com.example.com. Then click Check verification again.
Your organization’s plan doesn’t include SSO. Click Upgrade Plan or see Manage your subscription.
You’re signed in as an Admin or lower. Ask an organization Owner to make the change, or to change your role.
Check that the user is assigned to the CloudThinker app in your identity provider. If they still fail, an Owner can turn off Require SSO while you fix the IdP side.
Either Require SSO is off, the user’s email isn’t on a verified domain, or the user is an organization Owner, who is exempt by design.
Your identity provider isn’t sending first and last name. Fix the attribute mapping in the SAML or OIDC guide.
Sign-ins aren’t recorded in audit logs, so start from the message the user sees on the CloudThinker sign-in page:

​
Next steps

SAML setup

Step-by-step SAML configuration for Okta, Entra ID, Google Workspace and more

OIDC setup

Step-by-step OIDC configuration for Google, Entra ID, Okta and others

SCIM provisioning

Let your directory add and remove users automatically

Roles and permissions

Decide what auto-provisioned users can do