Step 1: Review prerequisites
Before proceeding with SSO setup, confirm the following:- You have the Organization Owner role. Only Owners can manage SSO settings. If you’re not sure about your role, check Admin Settings → Organization.
- Your plan supports SSO. A Business or Enterprise subscription is required. Users on other plans see an upgrade prompt.
- You have admin access to your identity provider (e.g., Okta, Azure AD, Google Workspace, OneLogin) — you’ll need to create an application and copy configuration values.
- You can add DNS records for your company’s email domain — or can ask your IT team to do so.
CloudThinker supports both SAML 2.0 and OpenID Connect (OIDC). Choose whichever protocol your identity provider supports — if you’re unsure, SAML is the most widely supported option for enterprise identity providers.
Step 2: Verify your domain
Domain verification proves that your organization owns the email domain (e.g.,yourcompany.com). This prevents unauthorized organizations from claiming your domain. You need at least one verified domain before you can set up SSO.
Verifying your domain by itself will not impact existing users’ ability to access CloudThinker. Users are only affected once SSO is configured and explicitly enforced.
Navigate to Identity and access settings
Go to Admin Settings → Identity and access. In the Domain management card, click Add domain (or Manage domains if you already have domains).
Enter your domain
In the dialog, type your company domain (e.g.,
yourcompany.com) and click the + button to add it.Start verification
The domain appears in the domains table with a “Pending” status. Click Verify next to the domain to begin the verification process.
Add a DNS TXT record
CloudThinker generates a unique verification token. You (or your IT team) need to add a TXT record at your DNS provider (e.g., Cloudflare, Route 53, GoDaddy):
- Host / Name:
_cloudthinker(your DNS provider automatically appends.yourcompany.com) - Value: the token shown in the dialog (starts with
cloudthinker-domain-verification=) - TTL: use the default, or set to 3600
Step 3: Set up SSO with your identity provider
Once you have at least one verified domain, click Setup SSO on the Single sign-on card to open the setup wizard.Choose a protocol
The first step asks you to pick SAML 2.0 or OpenID Connect (OIDC). If your identity provider supports both, either will work — SAML is the more traditional choice, while OIDC requires fewer configuration values.| Protocol | Best for | What you’ll need from your IdP |
|---|---|---|
| SAML 2.0 | Most enterprise IdPs (Okta, Azure AD, OneLogin, Google Workspace) | Entity ID, SSO URL, and an X.509 certificate |
| OIDC | Modern IdPs (Okta, Azure AD, Auth0, Google) | Issuer URL, Client ID, and Client Secret |
- SAML Setup
- OIDC Setup
The SAML wizard has three steps: Protocol → SP Metadata → IdP Configuration.SP Metadata — CloudThinker displays the Service Provider values you need to enter in your IdP when creating the SAML application:
Copy these values into your IdP, then click Next.IdP Configuration — Now enter the values from your identity provider. You’ll find these in your IdP’s SAML application settings:
Tip: If your IdP provides a metadata URL or XML file, use the Import field at the top to auto-fill Entity ID, SSO URL, and certificate — this saves time and avoids copy-paste errors.Click Create Connection.
| Field | What to do with it |
|---|---|
| ACS URL | Paste this into your IdP’s “Reply URL” or “ACS URL” field |
| SP Entity ID | Paste this into your IdP’s “Audience” or “Entity ID” field |
| SP Metadata URL | Some IdPs let you import this URL to auto-fill all fields at once |
| Field | Where to find it |
|---|---|
| Display Name | Choose any name you like (e.g., “Okta SAML”) — this is just a label |
| Entity ID | Your IdP’s entity identifier (sometimes called “Issuer”) |
| SSO URL | Your IdP’s single sign-on endpoint URL |
| Certificate | The X.509 signing certificate from your IdP (base64-encoded) |
| SLO URL | (Optional) Single logout endpoint — only needed if you want users logged out of the IdP when they sign out of CloudThinker |
| NameID Format | Leave as “Email Address” unless your IdP requires a different format |
Step 4: Test your connection
Before rolling out SSO to your team, run a quick test to make sure everything is wired up correctly. Click Manage on the SSO card, then use the Connection test section in the Overview tab. CloudThinker checks different things depending on your protocol:| Protocol | What’s checked |
|---|---|
| SAML | IdP Entity ID is present, SSO URL is present, certificate is valid |
| OIDC | IdP discovery document is reachable, issuer URL matches, required endpoints exist, signing keys are accessible |
Step 5: Choose whether to require SSO
At this point, SSO is active but optional — your team can use it alongside password and OAuth login. If you want to require everyone to use SSO, turn on the Require SSO toggle on the SSO card.| Setting | What happens |
|---|---|
| Off (default) | SSO is available as a login option. Users can still sign in with email/password or OAuth. |
| On | All users with a verified domain email must use SSO. Password and OAuth login are blocked for those users. |
Step 6: Choose how users are added to your organization
The last step is deciding how new users get into CloudThinker. This is controlled by the Provisioning & directory sync card that appears when SSO is active.Provisioning options
| Mode | How users are added | How roles work | How users are removed |
|---|---|---|---|
| Manual | You invite each user by email | You assign roles when inviting | You remove users manually |
| JIT (Just-in-Time) | Accounts are created automatically the first time someone signs in via SSO | Everyone gets a default role you choose (Viewer, Developer, or Admin) | You remove users manually |
| SCIM | Users are synced automatically from your identity provider | Roles can be set per group | Users are removed automatically when removed from your IdP |
- Default role — the organization role assigned to new users (defaults to Viewer)
- Default workspaces — which workspaces new users are automatically added to (at least one is required)
Set up SCIM provisioning
Automate user and group provisioning from your identity provider with SCIM 2.0
JIT and SCIM are mutually exclusive. Switching to SCIM automatically disables JIT. Switching away from SCIM revokes the SCIM token and stops directory sync.
How users sign in with SSO
Once SSO is set up, here’s what your team members will experience:- On the CloudThinker login page, click Sign in with SSO
- Enter your team domain (e.g.,
your-company.com) - CloudThinker recognizes the domain and redirects to your identity provider
- Sign in with your IdP credentials (and complete MFA if required)
- You’re redirected back to CloudThinker and signed in
Managing your SSO connection
After setup, click Manage on the SSO card to open a panel with two tabs:- Overview — see your connection status, protocol, display name, verified domains, SCIM status, and creation date. From here you can activate, deactivate, delete, or test the connection.
- Configuration — update your IdP settings at any time. For SAML: edit Entity ID, SSO URL, certificate, SLO URL, and NameID format (your SP Metadata is shown for reference). For OIDC: edit Issuer, Client ID, and Client Secret (leave the secret blank to keep the existing one).
Updating your IdP certificate
IdP signing certificates expire periodically (often annually). When your IdP rotates its certificate:- Click Manage on the SSO card
- Go to the Configuration tab
- Update the certificate field with the new base64-encoded certificate
- Click Save Changes
- Use Test connection in the Overview tab to confirm the new certificate works
Turning off SSO
You can turn off the Require SSO toggle at any time to make SSO optional again (users can go back to password login). To fully remove SSO, click Delete in the Manage panel. This permanently removes the SSO connection, all linked user identities, and any SCIM configuration. Users will need to sign in with a password until a new connection is set up.Troubleshooting
SSO login redirects but fails
This usually means there’s a mismatch between CloudThinker and your IdP. For SAML, double-check that the ACS URL and Entity ID in your IdP exactly match the SP Metadata values shown in CloudThinker. For OIDC, verify the redirect URI in your IdP matches what CloudThinker expects.Domain verification keeps failing
DNS changes can take up to 48 hours to propagate. Make sure the TXT record is set on_cloudthinker (not the root domain). Some DNS providers require the full host as _cloudthinker.yourcompany.com — check your provider’s documentation.