Single sign-on
Company administrators set up single sign-on (SSO) under Admin, Single sign-on. Each company can connect its own identity provider, provision people with SCIM 2.0 and set its own sign-in policy.
Before you start
- You need to be a company administrator in Thoshika and an administrator in your identity provider.
- You need access to your domain's DNS to add a TXT record.
- Keep at least one company administrator who can sign in with a password or passkey while you test.
1. Verify your domain
- Under Domains, add your email domain, for example
example.co.in. - Add the TXT record shown at
_thoshika.followed by your domain, in your DNS. - Choose Verify. A domain can belong to only one company.
People whose email is on a verified domain are sent to your identity provider when they type their email on the sign-in screen.
2. Connect your identity provider
- Under Identity providers, choose a preset (Microsoft Entra ID, Google Workspace or Okta) or a generic SAML 2.0 or OpenID Connect provider.
- Create the application in your identity provider using the values Thoshika shows.
- Enter the provider's metadata URL or XML (SAML) or discovery URL, client ID and secret (OpenID Connect).
- Choose which verified domains route to this provider. You can connect several providers, with each domain routed to one.
- Test the sign-in in a private browser window.
Signing certificates are re-read from the metadata URL, so rollover needs no change in Thoshika.
3. Choose how accounts are created
- Just in time: an account and company membership are created the first time someone signs in through SSO, with the default roles you choose.
- SCIM 2.0: your identity provider creates, updates and deactivates users. Under Provisioning, create a SCIM token and give your provider the SCIM base URL and token. Groups pushed by the provider can be mapped to Thoshika roles (never to company administrator). Deactivating a user in the provider ends their sessions in your company.
4. Set the sign-in policy
| Setting | What it does |
|---|---|
| Enforce SSO | People on your verified domains can sign in only through SSO. Up to five company administrators keep a password as break-glass accounts. |
| Allowed methods | Which of password, passkey and SSO your company accepts. |
| MFA | Required for nobody, administrators or everyone. Passkeys, authenticator codes and SSO all count. |
| Session timeouts | Idle timeout and maximum session length. |
| IP allowlist | Sign-in and every API call must come from your listed network ranges. Thoshika refuses a list that would lock you out. |
Enforcing SSO needs a verified domain, a working provider and at least one break-glass administrator.
Mobile apps
SSO works on the mobile apps. The app opens your provider in the browser and returns to the app with a one-time code.
Sign-in log
Sign-in log lists successful sign-ins, failures and blocks, with the method, provider and IP address.
Not available yet
Policies per group rather than per company, signed requests and encrypted assertions, IdP-initiated sign-in, single logout and SCIM bulk operations are on the roadmap. Sign-in starts from Thoshika (service-provider initiated).