SAML Single Sign-On (SSO)
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 Kinsta, SAML SSO lets you connect your company’s IdP directly to MyKinsta. By creating a SAML application in your IdP and adding the connection details to MyKinsta, your team can sign in using their existing company credentials, eliminating the need to create or manage separate MyKinsta passwords. This also gives company owners centralized control over who can access MyKinsta, directly through the IdP.
Kinsta 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:
Enable SSO in MyKinsta
When you set up SAML SSO, you can click Save and exit setup at any stage to store your progress and return later.
In MyKinsta, go to your username > 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 Kinsta icon, then upload it to your IdP application.
- SSO/ACS URL: This is the Kinsta endpoint your IdP redirects to after authentication. It processes the SAML response, verifies it, and establishes the user’s session in MyKinsta. Copy and paste this into the SSO/ACS/Recipient/Single sign-on URL field in your IdP.
- Entity ID: Kinsta’s unique identifier within your IdP, used to recognize Kinsta 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 Kinsta’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 Kinsta to confirm a user’s identity and grant access without requiring an additional login.
- Name ID format: Defines how Kinsta identifies users. This must be set to an email address format in the IdP.
- Required attributes: The attributes Kinsta requires from your IdP to complete the login process.
Kinsta 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 MyKinsta 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 MyKinsta 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 click Save and exit setup to store your progress and return later.
Set up Kinsta 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 MyKinsta
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 MyKinsta.
If the test is successful and you want to enable SAML, click Save and set changes live.
Your MyKinsta 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 Kinsta’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 MyKinsta 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 MyKinsta 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 MyKinsta credentials.
Exceptions
If mandatory SSO is enabled, you can add specific users to an exceptions list, allowing them to log in with their MyKinsta 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 exceptions. Select the user from the list and click Add exception.
Remove a user from exceptions
To remove a user from the exceptions list, click the trash can icon on the user and then click Remove exception.
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 MyKinsta company.
Just-in-time provisioning
Just-in-time (JIT) provisioning allows users authorized by your IdP to access your MyKinsta company without requiring an invitation. In most cases, this means anyone with an email address on your domain. When a user signs in to MyKinsta, they are directed through IdP SSO and do not need to create a separate MyKinsta 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 Change default role.
Enable JIT provisioning
Once you have set the default role, to enable JIT provisioning, click Enable, and then click Enable JIT provisioning.
Disable JIT provisioning
To disable JIT provisioning, click Disable, and then click Disable JIT provisioning. 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 MyKinsta.
Removing users
To fully revoke access, users must be removed from both MyKinsta and your identity provider (IdP).
- If SSO and JIT provisioning are enabled, removing a user from MyKinsta 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 MyKinsta 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 MyKinsta password. In this case, they can create one by selecting Forgot password on the MyKinsta login page.
Once SSO is disabled, all users will be required to use Kinsta’s Two-Factor Authentication (2FA).
For security, multiple failed login attempts may lock the account. If this happens, Kinsta will send an email containing a temporary login link so the user can regain access to MyKinsta.
To disable SSO, within Single sign-on, click Disable.
To confirm you want to disable SSO, click Disable SSO.
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 MyKinsta, 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.