Single Sign-On (SSO) Overview

Security Assertion Markup Language (SAML) Single Sign-On (SSO) allows users to securely access multiple applications using a single set of credentials, typically their company email and password. Instead of creating separate logins for each service, users authenticate once through a company-managed Identity Provider (IdP) such as Okta, OneLogin, Microsoft Entra, or Google Workspace. The IdP verifies the user’s identity and grants access to all connected applications without requiring additional logins. The organization centrally manages access control, authentication policies, and permissions, providing greater security, compliance, and administrative efficiency. With SAML SSO, company owners or IT administrators can link their corporate email domain (e.g., @mycompany.com) to the organization’s IdP. This ensures that anyone with a company email address is automatically recognized and securely authenticated when accessing approved tools and services. At Sevalla, SAML SSO lets you connect your company’s IdP directly to Sevalla. By creating a SAML application in your IdP and adding the connection details to Sevalla, your team can sign in using their existing company credentials, eliminating the need to create or manage separate Sevalla passwords. This also gives company owners centralized control over who can access Sevalla, directly through the IdP. Sevalla supports all identity providers (IdPs) that use the SAML standard, including Microsoft Entra ID, Okta, OneLogin, Google Workspace, Auth0, Duo, JumpCloud, and more.

​

Set up SAML SSO

For detailed step-by-step guides for the most popular IdPs, refer to one of the following:

• Google Workspace SAML SSO
• Microsoft Entra SAML SSO
• Okta SAML SSO
• OneLogin SAML SSO
• Ping Identity SAML SSO

​

Enable SSO in Sevalla

When you set up SAML SSO, you can navigate away from the SSO setup at any stage to store your progress and return later. In Sevalla, go to your Settings > Single sign-on, and click Enable. Read through the introduction, which explains how SSO will be set up, and click Continue.

​

Set up the app integration in your IdP

Use the information provided within Create SAML app to set up a SAML app within your identity provider, and then click Continue.

• App name: Copy and paste this into the Application Name field in your IdP.
• App description: Copy and paste this into the Application Description field in your IdP. This field is typically optional.
• App icon: Click Download to get the Sevalla icon, then upload it to your IdP application.
• SSO/ACS URL: This is the Sevalla endpoint your IdP redirects to after authentication. It processes the SAML response, verifies it, and establishes the user’s session in Sevalla. Copy and paste this into the SSO/ACS/Recipient/Single sign-on URL field in your IdP.
• Entity ID: Sevalla’s unique identifier within your IdP, used to recognize Sevalla as the service provider. Copy and paste this into the Entity ID/Audience URI/Audience field in your IdP.
• Start URL: The web address for Sevalla’s SSO access portal. This is the entry point users visit to log in using SSO, triggering the SAML authentication request to the IdP. Copy and paste this into the Start URL/Login URL field in your IdP.
• Signed Response: A signed response provides secure digital verification, allowing Sevalla to confirm a user’s identity and grant access without requiring an additional login.
• Name ID format: Defines how Sevalla identifies users. This must be set to an email address format in the IdP.
• Required attributes: The attributes Sevalla requires from your IdP to complete the login process.

​

Sevalla setup

​

Email domain

In the Domain name, enter the email domain users will use to sign in using SAML SSO, and click Add domain. Only Sevalla accounts with an email address matching the verified domain can authenticate via SAML. For example, if SAML is enabled for example.com, only users with an @example.com email address will be able to sign in for that company. If the domain has already been verified in Sevalla through DNS management or as a site domain, it will automatically be verified. If it hasn’t, you’ll be prompted to add a TXT record to your DNS management service to confirm domain ownership. Because DNS changes can take time to propagate, you can navigate away from the SSO setup to store your progress and return later.

​

Set up Sevalla SAML

When the domain has been verified, use the information provided from your IdP to complete the SSO URL, Entity ID, and Public certificate, and then click Continue.

​

Test the authentication in Sevalla

To check everything is set up correctly, click Test authentication. A notification appears if the test was successful or if the test fails. If the test fails, click Back and check your SAML settings within your IdP and within Sevalla. If the test is successful and you want to enable SAML, click Save and set SSO live. Your Sevalla company users will now be able to sign in with SAML SSO or by entering their username and password. If you want to force users to sign on via SAML, you can enable Mandatory SSO. Users who sign in through an IdP are not required to complete Sevalla’s 2FA, as authentication is handled directly by the IdP.

​

Mandatory single sign-on

To require all users to log in with SSO, enable mandatory SSO. With this setting, all users are prompted to sign in via the identity provider (IdP) rather than their Sevalla credentials. If a user has already authenticated with SAML elsewhere, they’ll automatically be logged in. If a user switches companies to a company that does not have SSO enabled, they must enter their Sevalla credentials. You can also add Exceptions to allow specific users to log in with a password even when mandatory SSO is enabled. This is useful for 3rd parties that need to access your company but don’t have an email address in your domain, such as developers. If mandatory SSO is enabled but SAML is not enabled, users will be required to log in with their Sevalla credentials.

​

Exceptions

If mandatory SSO is enabled, you can add specific users to an exceptions list, allowing them to log in with their Sevalla credentials instead of SSO. This is useful for 3rd parties that need to access your company but don’t have an email address in your domain, such as developers.

​

Add a user to exceptions

To add a user to the exceptions list, click Add exception. Select the user from the list and click Add.

​

Remove a user from exceptions

To remove a user from the exceptions list, click the trash can icon next to the user, then click Continue. When you remove the last user from the exceptions list, a warning message will appear. If all users are removed and an issue occurs with the IdP, you may lose access to your Sevalla company.

​

Just-in-time provisioning

Just-in-time (JIT) provisioning allows users authorized by your IdP to access your Sevalla company without requiring an invitation. In most cases, this means anyone with an email address on your domain. When a user signs in to Sevalla, they are directed through IdP SSO and do not need to create a separate Sevalla account. By default, users provisioned through JIT are assigned the Company Developer role. You can adjust each user’s access level after they join, or update the default role to define the access level new JIT-provisioned users receive upon joining.

​

Change default role

When JIT provisioning is enabled, users are assigned the Company Developer by default. To change their default access level, click Change default role. You can then choose the access level you want to assign to users who join via JIT provisioning, and click Save changes.

​

Enable JIT provisioning

Once you have set the default role, to enable JIT provisioning, click Enable, and then click Continue.

​

Disable JIT provisioning

To disable JIT provisioning, click Disable, and then click Continue. If you disable JIT provisioning and SSO, users created through JIT will be prompted to set a password the next time they log in to Sevalla.

​

Removing users

To fully revoke access, users must be removed from both Sevalla and your identity provider (IdP).

• If SSO and JIT provisioning are enabled, removing a user from Sevalla alone will not block access. The user can still sign in through your IdP.
• If you remove a user only from your IdP and mandatory SSO is not enabled, the user can still log in with their Sevalla credentials.

​

Change the session duration

Your identity provider (IdP) controls the duration and expiration of your SSO session. Refer to your IdP’s supporting documentation for information about how to change this.

​

Disable SSO

If you disable SSO, users will no longer be able to sign in using SAML SSO and must instead log in with their email address and password. If JIT provisioning was previously enabled, some users may not have an existing Sevalla password. In this case, they can create one by selecting Forgot password on the Sevalla login page. Once SSO is disabled, all users will be required to use Sevalla’s Two-Factor Authentication (2FA). For security, multiple failed login attempts may lock the account. If this happens, Sevalla will send an email containing a temporary login link so the user can regain access to Sevalla. To disable SSO, within Single sign-on, click Disable.

​

What is the difference between SAML SSO and OAuth SSO?

SAML SSO and OAuth SSO both allow single sign-on, but they’re built for different use cases, technologies, and types of identities. SAML SSO is used by businesses and enterprises to provide employees with secure, company-managed access to internal tools. With SAML, you sign in once using your work email and password, and you’re automatically logged in to all approved apps, such as Sevalla, Slack, or Salesforce, without needing to remember separate passwords. Usually, your company’s IT team manages access centrally through the Identity Provider (IdP), deciding who can sign in and which tools they can access. This provides greater security, compliance, and easier management for larger teams. OAuth SSO, on the other hand, is most common for personal use. It lets you sign in to apps or websites using an existing personal account, such as Google, Apple, or Facebook, instead of creating a new one. This is linked to your personal identity rather than your organization, and the company cannot control who accesses which applications. This means that OAuth SSO is less suitable for enterprise-level access management.