Single Sign-On (SSO)
Single Sign-On lets your team log in to Omnivoo using your company's existing identity provider -- the same system they use for email, Slack, and other workplace tools. Instead of managing separate OTP logins, your team authenticates once through your IdP and gains access to Omnivoo automatically.
Why Use SSO
- Centralized access control — Manage who can access Omnivoo from your identity provider. When someone leaves the company, disabling their IdP account revokes Omnivoo access immediately.
- Fewer login steps — No OTP codes to wait for. Your team clicks one button and they are in.
- Stronger security — Leverage your IdP's security policies (MFA, conditional access, device trust) for Omnivoo logins.
- Compliance — Meet enterprise security requirements that mandate centralized authentication.
Supported Protocols
Omnivoo supports two industry-standard SSO protocols:
| Protocol | Best For | How It Works |
|---|---|---|
| SAML 2.0 | Enterprises with Okta, Azure AD, or PingIdentity | XML-based assertion exchange between your IdP and Omnivoo |
| OIDC (OpenID Connect) | Organizations using Google Workspace or modern IdPs | Token-based authentication built on OAuth 2.0 |
Both protocols provide the same end-user experience. Choose whichever your identity provider supports or your IT team prefers.
How SSO Works with Omnivoo
- A user goes to app.omnivoo.com and enters their company email.
- Omnivoo detects that the email domain has SSO configured.
- The user clicks the SSO login button and is redirected to your company's identity provider.
- The user authenticates with their company credentials (and any MFA your IdP requires).
- The IdP sends a signed assertion back to Omnivoo confirming the user's identity.
- Omnivoo logs the user in automatically.
SSO is tied to your company's verified email domain. All users with an email address on that domain will see the SSO login option.
Compatible Identity Providers
Omnivoo works with any SAML 2.0 or OIDC-compliant identity provider. Commonly used providers include:
- Okta
- Microsoft Azure AD / Entra ID
- Google Workspace
- OneLogin
- PingIdentity
If your provider is not listed here but supports SAML 2.0 or OIDC, it will work with Omnivoo.
Authentication Policies
When you enable SSO, you choose an authentication policy that controls how your team can log in:
| Policy | SSO | Email OTP / Google | Best For |
|---|---|---|---|
| Any Method | Available | Available | Gradual SSO rollout -- let your team try SSO without forcing it |
| SSO Preferred | Shown first | Available as fallback | Encouraging SSO adoption while keeping alternatives accessible |
| SSO Required | Required | Blocked | Full security lockdown -- all members must use your IdP |
What Happens When SSO Is Required
When you set the policy to SSO Required:
- Email OTP and Google OAuth login are blocked for all company members.
- Members who try to log in with OTP or Google will see a message directing them to use SSO.
- Only SSO authentication through your configured identity provider will be accepted.
The company owner always retains emergency OTP access, even when SSO is required. This is a break-glass mechanism to ensure you can still access your account if your identity provider experiences an outage.
What's Next?
- Setting Up SSO — Step-by-step configuration guide for admins
- SCIM Provisioning — Automate user provisioning from your IdP
- Logging In with SSO — End-user guide for signing in with SSO