Zuvo Docs

Guide

Enable SSO for Your Organization

General information about enabling single sign-on (SSO) for your organization

Zuvo offers single sign-on (SSO) as a login option to provide additional account security for your team. This allows company administrators to enforce the use of an identity provider when logging into Zuvo. SSO improves the onboarding and offboarding experience of the company as the employee only needs a single set of credentials to access third-party applications or tools which can also be revoked by an administrator.

Supported providers

Zuvo supports practically all identity providers (IdP) that support the SAML 2.0 SSO protocol. These guides cover commonly used identity providers to help you get started. If you use a different provider, contact support.

Once configured, you can update your settings anytime from the SSO section of the dashboard under Organization Settings.

SSO Example

Choosing your login flow

Zuvo supports two SSO login flows: IdP-initiated and SP-initiated. You can enable one or both depending on your organization's needs.

IdP-initiated login (recommended)

Users start their login from your identity provider (Okta, Azure AD, Google Workspace) by clicking an app tile or bookmark. This is the simplest and most common configuration - it requires no domain configuration and works automatically once SSO is enabled.

Best for:

  • Organizations with established IdP workflows
  • Multiple SAML apps per domain (Dev, Staging, Prod)
  • Simplest user experience

SP-initiated login

Users start their login at zuvodev.com by entering their email address, then are redirected to your identity provider. This flow requires configuring email domains to route users to the correct IdP.

Best for:

  • Users who bookmark zuvodev.com directly
  • Organizations migrating from password authentication
  • Supporting domain-based automatic IdP routing

Need help choosing?

Key configuration options

  • Login flows - Choose between IdP-initiated (users start from identity provider), SP-initiated (users start at zuvodev.com), or both. IdP-initiated is recommended for most organizations and requires no domain configuration. See Choosing the Right Login Flow for guidance.
  • Email domains - Required only if you enable SP-initiated login. You can associate one or more email domains with your SSO provider. Users with matching email addresses can sign in via SSO at zuvodev.com. Not required for IdP-initiated flow.
  • Auto-join - Optionally allow users with a matching domain to join your organization automatically when they sign in via SSO. This applies on every login, not only on first signup.
  • Default role for auto-joined users - Choose the role (e.g., Read-only, Developer, Administrator, Owner) that automatically joined users receive. We recommend using Developer as the default (principle of least privilege) and promoting users individually as needed. Refer to access control for more information about roles.
  • Invitation types - When inviting users to your organization, you can explicitly choose whether the invitation requires SSO authentication or allows non-SSO login (password/social). This enables mixed authentication organizations with both SSO and non-SSO users.

How SSO works in Zuvo

When SSO is enabled for an organization:

  • Organization invites are restricted to company members belonging to the same identity provider.
  • Every user has an organization created by default. They can create as many projects as they want.
  • An SSO user will not be able to update or reset their password since the company administrator manages their access via the identity provider.
  • If an SSO user with the following email of alice@foocorp.com attempts to sign in with a GitHub account that uses the same email, a separate Zuvo account is created and will not be linked to the SSO user's account.
  • SSO users will only see organizations/projects they've been invited to or auto-joined into. See access control for more details.

Enabling SSO for an organization

Recommended workflow:

  1. Create or verify at least one non-SSO owner account exists (required for safety)
  2. Configure your SSO provider following one of our provider-specific guides
  3. Start with auto-join disabled to test the configuration
  4. Test SSO login with your own account
  5. Once confirmed working, enable auto-join if desired
  6. Thoroughly test using our SSO Testing and Best Practices guide
  7. Invite users to the organization or let them auto-join on login

Disabling SSO for an organization

If you disable or delete the SSO provider for an organization, all SSO users will immediately be unable to sign in.

Removing an individual SSO user's access

To revoke access for a specific SSO user without disabling the provider entirely you may:

  • Remove or disable the user's account in your identity provider
  • Downgrade or remove their permissions for any organizations in Zuvo.

Testing and best practices

Before rolling out SSO to your organization, we strongly recommend thorough testing and following security best practices. Our comprehensive guide covers:

  • Step-by-step testing procedures for SSO login, auto-join, and invitations
  • Troubleshooting common issues (many of which previously required support intervention)
  • Security best practices including certificate monitoring and domain configuration
  • Operational guidance for making SSO changes safely
  • Pre-launch verification checklist

Visit the SSO Testing and Best Practices guide for complete details.

Advanced scenarios

Most organizations use a single SSO provider for all users. However, Zuvo supports multiple SSO providers within an organization for advanced use cases such as:

  • Separate providers for development, staging, and production environments
  • Different providers for different teams or business units
  • Gradual migration from one identity provider to another

If you need to configure multiple SSO providers, refer to the Multiple SSO Providers guide for detailed configuration steps, and contact your Zuvo support representative if you need additional guidance.

Enterprise-managed authentication for MCP

Once SSO is configured, you can let your identity provider automatically authorize MCP clients for your organization, without individual members having to approve each one. See Enterprise-Managed Authentication for MCP for details.