> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sevalla.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Single Sign-On (SSO) Overview
> Find out how to set up SAML SSO with Sevalla.
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.
When using SAML SSO with Sevalla, login must always be initiated from Sevalla. Logging in directly from your Identity Provider (IdP) is not supported.
IdPs only support one active session per browser. If you have multiple accounts and are logged into one, attempting to log into another through Sevalla will result in an error. To switch accounts, log out of your IdP or use your browser’s Incognito/Private mode.
## 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](https://docs.sevalla.com/company-settings/single-sign-on/google)
* [Microsoft Entra SAML SSO](https://docs.sevalla.com/company-settings/single-sign-on/microsoft)
* [Okta SAML SSO](https://docs.sevalla.com/company-settings/single-sign-on/okta)
* [OneLogin SAML SSO](https://docs.sevalla.com/company-settings/single-sign-on/onelogin)
* [Ping Identity SAML SSO](https://docs.sevalla.com/company-settings/single-sign-on/ping)
### 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 **Company 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.
As Sevalla is a [**Kinsta**](https://kinsta.com/) product, we use `my.kinsta.com` in the **SSO/ACS URL**, **Entity ID**, and **Start URL.** This is a normal part of the Sevalla experience.
### 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.
Each email address can only be linked to one SAML configuration in Sevalla. This means a domain (e.g., `example.com`) can be associated with only one company at a time. Similarly, each Sevalla user can use SAML authentication for a single company only.
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**.
Certificates can expire, so you may need to update this in the future. Company Owners and Company Administrators will receive a notification three weeks prior to certificate expiration to ensure the certificate is updated in a timely manner.
### 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.
We strongly recommend adding at least one user as an exception, such as the company owner, so you can still access your company with your Sevalla credentials if any issues occur with SAML SSO.
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.
We strongly recommend adding at least one user as an exception, such as the company owner, so you can still access your company with your Sevalla credentials if any issues occur with SAML SSO.
### 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.