Skip to content
English - United States
  • There are no suggestions because the search field is empty.

How to Configure SAML Single Sign-On (SSO)

Allow users to sign in to your app using their organization's existing login credentials instead of creating a separate password.

How to Configure SAML Single Sign-On (SSO)

Let your users log in with the same account they already use at your organization—no separate app password needed.

Single Sign-On (SSO) lets your members log in to your app using the account they already have with your company's login system—for example, their Microsoft, Google, or Okta work account. Instead of creating and remembering a separate password just for your app, they sign in with credentials they already know.

This article walks you through the setup one step at a time. You don't need to be technical to follow it—we explain each term as it comes up, and most of the work is simply copying a value from one screen and pasting it into another.

Important: After you finish SAML, continue to How to Configure SCIM User Provisioning to keep your user list in sync. If SCIM is not set up, your app will not stay in sync with your identity provider—profile updates and access removals will not flow through automatically, and you'll have to manage those changes by hand.

 

A few terms, in plain language

  • Identity provider (IdP) – Your company's login system that already stores your users, such as Microsoft Entra ID (formerly Azure AD), Okta, or Google Workspace. This is where people's usernames and passwords live.
  • SAML – The secure "handshake" that lets your app trust your identity provider to confirm who a user is. When SAML is on, logging in happens through your identity provider.

 

Requirements

  • Administrator access to your Control Panel.
  • Administrator access to your company's identity provider (for example, Microsoft Entra ID / Azure AD).
  • Your identity provider must support SAML 2.0. Most major providers do, including Microsoft Entra ID, Okta, Google Workspace, OneLogin, and Ping Identity.

 

Step 1 – Start a new sign-in integration in the Control Panel

  1. Log in to your Control Panel.
  2. Go to User Access → Settings.
  3. Click Add Sign-in Integration and select SAML.

 

Step 2 – Name and style your sign-in button

  1. Enter a name for this integration (for example, "Company Login") so you can recognize it later.
  2. Customize how the sign-in and registration button looks—choose the button color and icon your users will see.

 

Step 3 – Connect your identity provider to the Control Panel

Think of this step as introducing the two systems to each other. You'll grab one web link from your identity provider and paste it into the Control Panel, and it will fill in the rest for you. Keep both windows open side by side—your identity provider in one, the Control Panel in the other—so you can switch between them easily.

In your identity provider (for example, Microsoft Entra ID):

  1. Sign in to your identity provider as an administrator.
  2. Create a new enterprise application for your app. This is the "profile" your provider uses to talk to your app. If it asks you to pick a type, choose the option for a custom or non-gallery application, and give it a name you'll recognize (for example, "My App SSO").
  3. Open that application's Single Sign-On (SSO) settings and choose SAML if you're asked to pick a method.
  4. Look for a value called the metadata URL (it may also be labeled "App Federation Metadata URL" or "Metadata endpoint"). This is a single web link.
  5. Copy that metadata URL. Tip: use Copy rather than typing it by hand, so you don't miss a character.

 

Back in the Control Panel:

  1. Return to the SAML integration you started in Step 1.
  2. Find the metadata URL field and paste the link you just copied.
  3. Save or apply so the app can read the link.
  4. Confirm that three fields now fill in automatically: the Entity ID, the SSO URL, and the Signing Certificate. If they filled in, the connection worked—these are just the technical details your provider shared through that link, and you don't need to change them.

If the fields did not fill in: the link was likely incomplete or mistyped. Go back to your identity provider, copy the metadata URL again, and re-paste it into the Control Panel.

 

Step 4 – Send the app's details back to your identity provider

Now you'll do the reverse: copy two values from the Control Panel and paste them into your identity provider, so your provider knows exactly where to send users after they log in. Again, keep both windows open so you can copy from one and paste into the other.

In the Control Panel:

  1. In the same SAML integration, find the Entity ID and the Redirect URL (the Redirect URL may also be labeled "Reply URL" or "ACS URL"). These are two separate values.
  2. Copy the first value now, or copy each one just before you paste it in the next step.

In your identity provider:

  1. Go back to the enterprise application you created in Step 3 and open its SAML settings.
  2. Find the field for the Identifier (also called "Entity ID") and paste the Entity ID into it.
  3. Find the field for the Reply URL (also called "Assertion Consumer Service URL" or "ACS URL") and paste the Redirect URL into it.
  4. Set up your user attributes—these are the pieces of information your provider shares about each person when they log in. At a minimum, make sure it sends the user's email, first name, and last name. Most providers include these by default, so you may only need to confirm they're there.
  5. Find the Name ID attribute and leave it in place—do not remove it. This is required, and it's what uniquely identifies each user. It's usually set to the user's email address.
  6. Save your changes in the identity provider.

 

Step 5 – Save your configuration (do this before testing)

Important: Before you test anything, save your work in both places. Save the configuration in the Control Panel, and save the SAML configuration in your identity provider. If you skip saving, the test in the next step will fail even when everything is set up correctly.

 

Step 6 – Test the SAML connection

Note: The Test button is in your identity provider, not in the Control Panel. You run the test from your provider's Single Sign-On screen.

  1. Go to your identity provider and open the enterprise application you set up.
  2. Open its Single Sign-On (SSO) settings and find the Test option (in Microsoft Entra ID it appears as a Test button on the SAML sign-on page).
  3. Run the test and sign in with a test account when prompted.
  4. A successful test confirms the connection is working. If the test doesn't work, see the Troubleshooting section at the end of this article—and double-check that you saved in both places (Step 5).

 

Step 7 – Configure access and security

Where to find this: This step lives under App Properties, not inside the Single Sign-On configuration screen. It's a common point of confusion, so head to App Properties for this part.

  1. Open App Properties.
  2. Choose whether only assigned users can sign in (recommended if you want to limit access to specific people).
  3. Set the signing option to Sign SAML response and assertion. This tells your app to accept only properly secured logins.
  • Where to find it: This setting is inside App Properties, in the security or SAML section for your integration—look for a dropdown or list labeled Signing Options (it may also appear as "Response signing" or "Signing algorithm").
  • Open that dropdown and select Sign SAML response and assertion. If you see other choices such as "Sign response only" or "Sign assertion only," do not pick those—choose the option that signs both the response and the assertion.
  • Save your change.

 

Step 8 – Confirm everything works

  1. Ask a test user (or use a test account) to sign in through SSO.
  2. Confirm they are sent to your identity provider, then returned to the app and logged in successfully.

Pro tips

  • SAML handles logging in. It confirms who a user is through your identity provider. If you also want help keeping existing accounts up to date automatically, set up SCIM separately.
  • Users are created at first login. A member is added to your app the first time they sign in through SSO.
  • No new app build needed. Setting up SAML does not require rebuilding your app or resubmitting it to the app stores.
  • Next step: SCIM keeps your user list in sync automatically—pushing profile updates and removing access when someone leaves your organization. Without SCIM, your app will not stay in sync with your identity provider. Continue with How to Configure SCIM User Provisioning.

Troubleshooting tips

  • The test failed – Make sure you saved the configuration in both the Control Panel and your identity provider before testing (see Step 5). This is the most common cause.
  • Fields didn't auto-fill in Step 3 – Double-check that you copied the full metadata URL from your identity provider and pasted it correctly.
  • A user can't log in – Confirm the user is assigned to the app in your identity provider, especially if you chose "only assigned users can sign in" in App Properties.
  • Can't find the access/security settings – Remember these are under App Properties, not the Single Sign-On configuration screen.