SSO vs SAML
Why single sign-on matters, what SAML actually is, and how to keep your customers happy (and secure)
The TL;DR
- Single sign-on (SSO) is the experience: one set of credentials, many SaaS applications.
- SAML (Security Assertion Markup Language) is one of the protocols that make enterprise SSO possible.
- Modern B2B platforms typically support SAML SSO to connect to identity providers (IdPs) like Okta, Azure AD, Google Workspace, or Rippling.
- Often when customers ask, "Do you support SSO?" they are referring to Enterprise SSO, either via SAML or OIDC, not "Login in with Google"
What is Single Sign-on (SSO)?
Single Sign-on (SSO) is when you log in to one account and it gives you access to multiple products or sites.
Probably the most common example of this is a “Login with Google” button, and the idea is really simple. You have an account with Google, you’ve signed in to your account with Google, and then you get access to any site that has implemented this button.
Notably, the "Login with Google" button allows anyone with a Google account to login, including @gmail.com accounts. This is perfectly fine for many applications, but B2B applications are often looking for something stricter.
What is SAML / Enterprise SSO?
Enterprise SSO is a different flavor of SSO. The idea is still largely the same - a user should be able to have one single account and use that account to log in to multiple products.
There's a few key differences though:
- Instead of one global "Login with Google" button, you have one Enterprise SSO connection per customer.
- You and the customer need to coordinate to set up the connection.
- Instead of allowing anyone to login, each connection only allows employees of the company to log in.
- This is a small oversimplification - the company technically can choose which employees have access to each of the products. Often, managing employees access is done by an Identity Provider (IDP) like Okta, Azure/Entra, and Rippling.
SAML is one of the primary protocols to achieve this kind of SSO, where a user gets access to the products they need to do their job via their single work account with the identity provider.
A SAML Example
Let’s walk through a scenario to demonstrate what this looks like. Say an employee has just joined a new large company (Acme Co) as a sales representative. Acme Co knows that this employee is going to need access to Salesforce.
As part of their normal employee onboarding, the employee is added to the companies Identity Provider (e.g. Okta, Azure AD, Rippling, etc). The employee is then added to a group associated with the sales department.
Previously, the company configured their IDP to allow any employee in the Sales group to get access to Salesforce.
From here there are two possible paths:
IDP-Initiated Flow: The employee goes to their IDP employee dashboard, where they have a button for Salesforce. When they click it, they are immediately logged in and brought to Salesforce.
SP-Initiated Flow (short for Service Provider, which in this case, is Salesforce): The employee goes to Salesforce and they select to log in with their employee account in their IDP. Salesforce then redirects the user to their Identity Provider where the user will login. Afterwards, the user is redirected back to Salesforce.
In either of these cases, one other notable difference is that Salesforce knows that the user is a member of Acme Co, since they are logging in via the connection that Acme Co created. The employee won't need to be invited to Acme Co's tenant within Salesforce, they should get access immediately.
This is one of the biggest benefits for companies like Acme Co - all they had to do was add the employee to the Sales group, and the employee is immediately able to log in and get access to any products that they need to do their job.
Setting Up SAML
An important aspect of SAML is that each customer that wants to use it needs to set up a connection that is unique to them.
Ultimately, you need to provide your customer with values like an Entity ID (to identify your application), an ACS (Assertion Consumer Service) URL (which tells the IDP where to interact with your application), and optional fields like a Single Logout endpoint (SLO).
The customer needs to provide you with values like an Entity ID / Issuer (to identify them), a certificate (so you can validate their requests), an SSO URL (to know where to redirect users), and more.
The complicating factor here is that every IDP is a bit different, both for which terms they use and where the user can find them.
One thing we do at PropelAuth is provide SSO/SAML guides to walk the user through the process of setting up SAML, based on which IDP they choose.
It's been incredibly valuable for speeding the process along, since it allows the customer to fully set everything up without a lot of back and forth.
Summary
Single sign-on (SSO) is the user experience of logging in once and accessing multiple services; SAML is a protocol that makes enterprise-grade SSO possible. Consumer SSO buttons (e.g., “Login with Google”) admit any Google account, but B2B apps usually need a stricter, per-customer SAML connection that limits access to company employees.
In a typical rollout a company’s IdP (Okta, Azure AD, Rippling, etc.) is configured to grant a specific group - such as the Sales department - access to a product like Salesforce. Users sign in through either an IdP-initiated dashboard click or an SP-initiated redirect from the product. Because the SAML connection is tied to the customer’s tenant, the product knows instantly which organization the user belongs to and can grant access without manual invites.
Setting up SAML means each side exchanges a short set of identifiers and URLs:
- Service Provider (your app): Entity ID, ACS URL, optional SLO URL, certificate, etc.
- Identity Provider (customer): Issuer ID, SSO URL, certificate, optional SLO URL, etc.
Tools like PropelAuth streamline this exchange with step-by-step guides, letting customers complete the setup quickly and start using enterprise SSO without back-and-forth emails.
