Set up single sign-on (SSO)
Connect your identity provider so your team signs in to Clav with corporate credentials and, if you choose, make it the only way in.
What single sign-on gives you
With SSO, Clav stops being a separate account your team has to manage. Access follows your identity provider: your password policy, your multi-factor rules and your conditional access all apply, and revoking someone there removes their way into Clav.
One set of credentials
Your team signs in with the corporate account they already use every day.
Verified domain
A provider only becomes active once you prove, through DNS, that the email domain is yours.
Optional enforcement
Force SSO makes your identity provider the only accepted way to reach your data.
What signing in looks like
Once SSO is set up, signing in works like this:
Before you start
You need three things:
- To be the owner of the organisation in Clav.
- To be able to create applications in your identity provider (Okta, Microsoft Entra ID, Google Workspace, or any SAML 2.0 / OIDC provider).
- To be able to publish a DNS TXT record on the email domain your members use.
Supported protocols
Clav supports SAML 2.0 and OpenID Connect. No provider-specific extensions are required, so any conformant identity provider will work.
Connect your identity provider
Create the application in your identity provider
In your IdP, create an application for Clav and copy the values it gives you. For OIDC you need the issuer URL, the client ID, the client secret and the discovery endpoint. For SAML you need the issuer (entity ID), the sign-on URL and the signing certificate.
Open your organisation security settings
In the platform, go to your organisation’s settings and open the Security tab. Single sign-on is configured there, alongside the two-factor and enforcement policies.
Add the provider
Register the provider with the values copied from your IdP, and give the email domain your members use.
Verify the email domain
Click Verify domain. Clav shows a DNS TXT record name and value. Publish that record on your domain, wait for DNS to propagate, then run the check. The provider stays inactive until this succeeds, and that step is what proves the domain is yours.
Test the sign-in
Sign out and use Sign in with SSO with an address on the verified domain. Confirm that at least one administrator can get in through the identity provider before moving to the final step.
Optional: enforce SSO for everyone
Once you have confirmed SSO works, turn on Force SSO to make it the only way in. Email-and-password sign-in and Google sign-in are then rejected for every member of your organisation.
Proving the domain is yours
When you click Verify domain, Clav generates a DNS TXT record name beginning
with the clav-verification prefix, together with a unique value. Publish it on
the email domain you registered, then return to the dialog and run the check.
Until that check succeeds, the provider does not authenticate anyone. This is a deliberate safeguard: it stops a third party from registering a provider that claims your domain and intercepting your members’ sign-ins.
DNS propagation
TXT records can take from a few minutes to a few hours to propagate. If the check fails at first, wait and try again. You do not need to re-create the provider.
Making SSO the only way in
Force SSO is an organisation-level policy. With it enabled, every attempt to sign in with an email and password or with Google is rejected for members of your organisation, no matter how the request reaches Clav.
- Enforcement is applied on the server, before any session is created.
- Turning the policy on or off is restricted to the organisation owner.
- Every change is recorded in the audit log with the acting user, source IP and timestamp.
Test before you enforce
Confirm that at least one administrator can sign in through your identity provider before enabling Force SSO. If the provider is misconfigured or later becomes unreachable, your members cannot sign in and Clav support has to lift the enforcement for you.
Frequently asked questions
Which identity providers are supported?
Any provider that speaks SAML 2.0 or OpenID Connect. That includes Okta, Microsoft Entra ID (Azure AD), Google Workspace, OneLogin, JumpCloud, Ping Identity and Auth0. Clav does not depend on provider-specific extensions, so a conformant IdP will work even if it is not on this list.
Who can configure SSO?
Only the organisation owner. Registering, updating or removing a provider, and enabling Force SSO, are owner-only actions. Every one of them is written to the organisation’s audit log with the acting user, the source IP and the timestamp.
Why do I have to verify the email domain?
Domain verification proves that your organisation controls the email domain before Clav will route any sign-in through your identity provider. Without it, anyone could register a provider claiming your domain and intercept logins for your users. The provider stays inactive until the DNS TXT record is published and checked.
What happens to existing passwords when I enable Force SSO?
Passwords are not deleted, but they stop working. With Force SSO enabled, every email-and-password sign-in and every Google sign-in is rejected for members of your organisation; the only accepted path is your identity provider. Turning Force SSO off restores the previous methods.
Can I test SSO before enforcing it?
Yes, and you should. After you verify the domain, the provider is active and users can sign in through it, while the existing methods keep working. Confirm that at least one administrator can sign in through the identity provider before you enable Force SSO. Enabling enforcement without testing can lock your team out.
What if my identity provider goes down while Force SSO is on?
Your users will not be able to sign in until the provider is reachable again, because Force SSO deliberately removes the fallback paths. If you need access restored urgently, contact Clav support so an operator can disable enforcement for your organisation.
Does SSO replace two-factor authentication?
It moves the responsibility to your identity provider. When members sign in through SSO, the multi-factor policy and any conditional-access rules configured in your IdP apply. Clav’s own require-two-factor policy governs accounts that authenticate directly with Clav.
Are new users created automatically on first SSO sign-in?
Membership is still invitation-controlled. A user signing in through your identity provider is joined to your organisation only when they have a valid invitation, so an account in your IdP does not by itself grant access to your Clav data.
Can I remove a provider later?
Yes. An owner can remove the provider at any time from Settings, and the removal is audit-logged. If Force SSO is enabled, turn it off first so your members keep a way to sign in.