With SSO your people sign in to Sprecho with the account they already have, and you keep control of access where it belongs — in your directory. This article walks through the setup, which takes about twenty minutes if DNS is quick.
You need to be the owner or an admin of a team on the Enterprise plan. Everything happens in the console at enterprise.sprecho.ai under SSO.
Which protocols does Sprecho support?
SAML 2.0 and OpenID Connect (OIDC). One identity provider is connected per team. The wizard offers presets for Microsoft Entra ID, Okta and Google, plus custom OIDC and custom SAML for anything else.
Setting it up
The console walks through six steps.
- Pick your identity provider. The preset adjusts the instructions in the following steps to that provider's terminology.
- Register Sprecho in your IdP. The console gives you the values to paste
there:
- SAML: the SP Entity ID and metadata URL, and the ACS URL
- OIDC: the redirect URI
- SCIM, if you use it: the SCIM base URL
- Paste your IdP's credentials back into Sprecho. For SAML you can paste the whole federation metadata XML and Sprecho extracts the entity ID, the sign-on URL and the signing certificate for you — or fill the three fields by hand. For OIDC you enter the issuer, client ID and client secret. The secret is encrypted at rest and never shown again.
- Verify your domain (see below).
- Test the sign-in with a real account before anyone depends on it.
- Enable it, decide whether to enforce it, and pick the default role for people who arrive through SSO.
Sprecho refuses to enable an incomplete configuration, so a half-filled form cannot lock anyone out. Every change is written to the audit log and emailed to the team owner.
Verifying your domain by DNS
Domain verification is what lets Sprecho route someone typing
name@yourcompany.com to your identity provider.
- Add the domain in the console. You get a token that looks like
sprecho-verify-…. - Create a TXT record at
_sprecho-verification.yourcompany.comwith that token as its value. - Click Verify. Sprecho queries public DNS resolvers directly, so it sees the record as soon as it propagates.
If the lookup fails, the console repeats the exact record it expected. Free mailbox domains such as gmail.com are rejected, and a domain can belong to only one Sprecho team.
What your people see
At the sign-in screen they type their work email address. Sprecho recognises the verified domain, replaces the password field with Continue with SSO, and hands them to your provider. After they authenticate, a short page tells them they can close the window and return to Sprecho.
If you switch on enforce SSO, password sign-in stops working for every address on your verified domains — including passwords set before SSO existed. Test the sign-in first: enforcement is what turns a misconfiguration into a locked-out team.
The first time someone signs in through SSO, Sprecho creates their account automatically and takes a free licence for them. If no seat is available the sign-in fails, so keep spare seats before a rollout. See how Enterprise licences and seats work.
SCIM provisioning
SSO decides who may sign in. SCIM keeps membership in step with your directory without anyone signing in at all.
- Generate a SCIM token in the console. It is displayed once — store it in your provider immediately. Tokens last a year by default; you can set anything between 30 days and five years, or no expiry, and the owner is warned by email before one lapses.
- Point your provider at the SCIM base URL with that token as the bearer credential. Sprecho implements SCIM 2.0 for Users and Groups, with filtering and PATCH.
- Deactivating or deleting a user in your directory removes their Sprecho membership, returns their licence to the pool and invalidates their sessions immediately. The team owner cannot be removed this way — transfer ownership first.
- Map a directory group to a Sprecho role so that membership of, say, an IT group makes someone an admin. Role changes apply straight away.