Single Sign-On (SSO)

Enterprise workspaces can let their team sign in through the company's identity provider, so access to Zernio follows the accounts your IT team already manages. Both SAML 2.0 and OIDC are supported, which covers Okta, Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud, and most others.

SSO is available on Enterprise agreements. If your plan doesn't include it, the setup panel will say so; talk to us to enable it.

How it works

A connection links one email domain to one identity provider. Anyone who signs in through that connection with an email at your domain lands in your workspace, as a new team member on first sign-in. Sign-in routes by email domain: your team enters their work address on the sign-in page and Zernio sends them to your IdP, no workspace slug to remember.

Three rules keep this safe:

• Only the workspace owner can set up SSO. It decides who can reach the whole workspace, so it sits with the person who owns the billing relationship, not with admins.
• The domain must be the owner's own email domain, and it can never be a public mailbox domain like gmail.com. You prove control of it with a DNS record before the connection routes a single sign-in.
• One connection per domain across all of Zernio. First verified claim wins; if your domain is already connected to another workspace unexpectedly, contact support.

Setting it up

Everything happens in Settings → Single sign-on.

1. Claim your domain and connect the IdP

Enter your company domain (it must match your own email address) and your identity provider's details:

• SAML: paste your IdP's federation metadata XML. Zernio reads the sign-on URL and certificate from it, so there's nothing to copy field by field. In Okta, Entra or OneLogin, download the app's federation metadata file and paste the whole thing. If your IdP can't export metadata, the sign-on URL, issuer, and certificate can be provided individually.
• OIDC: provide the issuer URL, client ID, and client secret from the app you created in your IdP.

When creating the app on the IdP side, the service-provider endpoints follow this shape (the providerId is shown in the settings panel once the connection exists):

Most IdPs let you create the app first with a placeholder ACS/redirect URL, export the metadata, connect it to Zernio, and then paste the final URLs back into the IdP.

2. Verify the domain over DNS

After connecting, Zernio shows a TXT record (host and value) to add at your DNS provider. The connection routes no sign-ins at all until this record is verified; that's what stops anyone else from registering an identity provider for a domain they don't own. DNS changes usually propagate within minutes; click Verify once the record is live. The record stays visible in the panel until verification passes.

3. Test it

Sign in through the identity provider yourself: on the sign-in page, choose SSO and enter your work email. Team members signing in for the first time are added to your workspace automatically with the connection's default role. The owner role can never be granted through SSO; ownership stays a deliberate, individual action.

Enforcing SSO

Once verified, the owner can flip on enforcement for the domain. From that moment:

• Password and Google/GitHub sign-in are refused for every account at your domain, with a message pointing people to SSO instead.
• This is enforced at session creation for every sign-in path, so it can't be stepped around by picking a different button.
• Existing sessions are untouched and ride until they expire; nobody gets logged out at the moment the switch flips.

One deliberate guard: enforcement stays locked until the owner has signed in through the connection at least once. Turning off every other door before proving the SSO door opens would lock the whole company out.

Removing a connection

The owner can disconnect SSO from the same panel. Removing it restores the other sign-in methods for your domain. You'll be asked to type the domain to confirm: this is the one action that can leave a whole company unable to sign in, and there is no undo.

Provisioning with SCIM

A verified connection can also drive SCIM 2.0 directory sync: your IdP creates accounts for joiners, syncs attribute changes, and deactivates leavers, with no invites to accept. See SCIM provisioning.

MFA and conditional access

With SSO connected, multi-factor authentication and conditional-access policies are your identity provider's job, and apply on every sign-in exactly as your IT team configured them. Zernio's own two-step verification covers password sign-in and isn't needed for SSO users.