Once more than a handful of people use Chat.co, the interesting security question stops being “who has a strong password” and becomes “what happens the day someone leaves”. SSO answers it: disable the account in your identity provider and Chat.co access goes with it, with no manual step anyone can forget.
1. What SSO gives you
Offboarding that actually works
Access is your identity provider's decision, not a checklist item in a leavers process.
Your policies, everywhere
MFA, conditional access, device posture, session length — whatever you enforce at the IdP now applies here too.
Provisioning on first login
A new hire signs in and gets an account at the role you configured. No invitation to chase.
One audit trail
Sign-in activity lives in the same place as the rest of your access logging.
2. What you need
- An OIDC identity provider. Okta, Microsoft Entra ID, Google Workspace, or any compliant provider.
- Permission to create an application in it. Usually an IdP administrator.
- Control of your email domain's DNS. You will publish a TXT record to prove ownership.
- Owner or team-management access in Chat.co. See team, roles & seats.
3. Configure your provider
Create an OIDC web application in your IdP. The setup guide inside Chat.co gives provider-specific paths; broadly:
| Provider | Where to create the app |
|---|---|
| Okta | Admin → Applications → Create App Integration → OIDC – OpenID Connect → Web Application |
| Microsoft Entra | Entra admin centre → App registrations → New registration |
| Google Workspace | Google Cloud Console → APIs & Services → Credentials → Create credentials → OAuth client ID |
Whatever the provider, you come away with three values:
| Value | What it is |
|---|---|
| issuer | The IdP’s base URL — for Okta, your org URL such as https://acme.okta.com. Chat.co uses it to discover the rest of the endpoints. |
| clientId | The application identifier your IdP generated |
| clientSecret | The application secret. Stored encrypted, and never returned by any API — if you lose it, generate a new one at the IdP. |
4. Create the connection
- 1
Enter issuer, client ID and secret
The three values from the previous section.
- 2
List your email domains
The domains whose users should sign in through this connection —
acme.com, and any others your people use. - 3
Choose the default role
What a user provisioned by SSO becomes on first login: team member or admin. Team member is almost always the right answer — you can promote individuals afterwards.
- 4
Test before you save
The connection form has a test action that checks your OIDC configuration actually reaches the identity provider. Use it on the values you have typed, before committing them.
5. Verify your domain
Listing a domain on a connection requests it. Traffic only routes to your SSO once you have proven you own it — otherwise anyone could claim yourcompany.com and intercept your sign-ins.
Chat.co gives you a TXT record per domain. Publish it in your DNS:
Host: _chatco-sso.acme.com Type: TXT Value: chatco-sso-verification=<token shown in the dashboard>
Then trigger verification from the connection. Once the record resolves, the domain is verified and starts routing.
A domain can be verified by exactly one connection. If verification is refused because the domain is already claimed, that is the protection working — get in touch rather than working around it.
6. Enforcing SSO
A connection has two independent switches, and the difference matters:
| Switch | Effect |
|---|---|
| Enabled | SSO works. Users on a verified domain can sign in through your IdP, and the ordinary email sign-in still works alongside it. |
| Enforced | SSO is the only route. Users on that domain can no longer sign in with an emailed code — every login goes through your IdP. |
Keep at least one owner account on a domain that is not enforced, or otherwise able to reach the account another way. It is the cheapest insurance available against an identity provider outage.
7. Troubleshooting
| Symptom | Most likely cause |
|---|---|
| The IdP rejects the request immediately | Redirect URI mismatch. Compare what the SSO setup screen shows against what is registered at the IdP, character for character. |
| Sign-in succeeds at the IdP but Chat.co refuses | The domain is listed but not verified, or the email address the IdP returned is on a domain the connection does not cover. |
| Domain verification keeps failing | The TXT record is not resolving yet, or was created on the wrong host. It must be _chatco-sso.<your-domain>, not the bare domain. |
| Users land with the wrong role | The connection’s default role applies at first login only. Change existing people on the Team page; change the default for future ones. |
| Nobody on the domain can sign in at all | Enforcement is on and the connection is broken. Contact support — this is why the previous section says to enforce last. |