SSO vs SAML, explained for everyone
SSO, SAML are often used vaguely and can be interpreted in different ways. In this article, we’ll clarify these concepts, explain how they relate to each other, and provide real examples to make them easier to understand.
Product & Design
SSO, SAML are often used vaguely and can be interpreted in different ways. In this article, we’ll clarify these concepts, explain how they relate to each other, and provide real examples to make them easier to understand.
What is SSO?
SSO (Single Sign-On) is an authentication process that lets a user log in once and access multiple applications or services without needing to log in again for each one. However, this general definition can apply to different scenarios when SSO is used.
There are various scenarios where SSO comes into play.
Social SSO
Sometimes, people refer to social login as social SSO. For example, users can use Google sign-in to create an account in a new app, directly using the identity and information stored in Google. In this scenario, the user manages their own identity.
Social SSO makes it easier for users to control their information, reducing the tedious steps in the account creation and login process. Social SSO typically relies on open standard protocols like OAuth 2.0 and OIDC.
Enterprise SSO
First, let’s break down the concepts of Identity Provider and Service Provider in simple terms.
- Identity Provider (IdP) is like the “gatekeeper” of your identity. It’s the system that holds your login information and verifies who you are. Think of it as a trusted authority that says, “Yes, this person is who they claim to be.” Examples include Google Workspace, Microsoft Entra, and Okta Workforce Identity.
- Service Provider (SP) is the “application” or “service” you want to access once your identity is verified. It’s the place where you’re trying to log in, like an app or website. For instance, Zoom, Slack, or your company’s internal tools are all service providers.
In simple terms, the Identity Provider proves who you are, and the Service Provider gives you access to its services once your identity is confirmed.
Enterprise SSO is used in more business-focused scenarios and divided by those two terms explained above, there are two typical cases: IdP-initiated SSO and SP-initiated SSO. While the terms might sound technical, the scenarios are actually quite straightforward.
IdP-initiated SSO
Think about when you, as an employee, onboard to your company’s applications and resources. Typically, HR will create an account for you. You then use that account to log in to a platform like Okta or Google Workspace. Once logged in, you’ll be directed to a corporate portal, where you can access all the company’s applications, such as payroll systems, collaboration tools, Workday, and more.
SP-initiated SSO
Let’s switch gears and look at it from another perspective. Sometimes, you need to start at a specific product’s login page. For example, if you want to use Zoom for an online meeting with your colleagues, you’ll see an option to “Log in with SSO.” This scenario is known as SP-initiated SSO.
What problems Enterprise SSO is solving
The first benefit of enterprise SSO is that it allows businesses to manage workforce identities easily, flexibly, and securely.
Let’s say you run a company, and all your employees need access to the products and services you’ve purchased. Since the resources produced by the company belong to the company, a corporate-owned identity system is needed. If employees were to use personal identities to access company resources, it would create security and management challenges.
On the other hand, in a scenario like SP-initiated SSO, employees access multiple applications and services owned by the company. When employees onboard or offboard, HR must create and delete numerous accounts across all the company’s products and services, which is tedious and time-consuming.
Enterprise SSO simplifies this process through a universal identity system, and tools like SCIM (System for Cross-domain Identity Management) and Just-in-Time provisioning make it even more efficient.
For IdP-initiated SSO, it’s beneficial for product builders who want to be “enterprise-ready.” For example, if you’re a startup that initially focuses on individual consumers, and later a large enterprise wants to use your product, they may require employees to log in using Microsoft Entra, for instance. In this case, you would need to integrate enterprise SSO into your product to close the deal.
What is SAML?
SAML (Security Assertion Markup Language) is an open standard protocol used for authentication and authorization. Along with OAuth and OIDC, SAML is widely used in identity management systems, particularly in workforce identity management. Commercial identity providers like Okta and Microsoft Entra commonly support SAML as one of their standard protocols.
Some older systems and social sign-in providers also offer SAML support, so having SAML built into your system can help ensure compatibility with a wider range of identity providers and future ecosystem growth.
When is SAML needed?
SAML is often used in Enterprise SSO scenarios. For example, consider this situation:
Your sales team reaches out to the product developers and says, “We’ve got a big client, and they require SAML sign-in. We need to support this technology.”
For engineers who are not familiar with SAML or IAM (Identity and Access Management), their first step would likely be to search for “SAML” or “SAML sign-in.”
Ultimately, the goal is to integrate enterprise SSO into your product, making it “enterprise-ready” to meet the needs of larger clients who rely on technologies like SAML for secure authentication.
How does SAML work
Here’s a simplified breakdown of the two types:
SP-Initiated Flow
- User attempts to access the SP’s resource.
- SP redirects the user to the IdP with a SAML authentication request.
- User logs in at the IdP and is authenticated.
- IdP generates a SAML assertion with the user’s identity and possibly authorization data.
- IdP sends the SAML assertion back to the SP, typically via the user’s browser.
- SP processes the assertion, validates it, and grants/denies access to the user.
IdP-Initiated Flow
- User is already logged into the IdP and selects a service/resource from the IdP’s portal.
- IdP generates a SAML assertion based on the user’s current session, containing identity and attributes.
- IdP sends the assertion directly to the SP, without the SP’s prior request.
- SP processes the assertion, validates its integrity, and extracts the user’s identity and attributes.
- SP grants or denies access based on the assertion.
To see how SAML works from a technical perspective, check out How does SAML work
The difference between SAML and SSO
SAML and SSO definitions are often mixed up, but here’s the simple breakdown:
- SSO is an authentication process used by apps and software, allowing users to log in once and access multiple services.
- SAML is a technical protocol mainly used in enterprise identity management to securely exchange authentication data.
Imagine this: You walk into your office in the morning, and instead of having to log into each application separately—your email, calendar, project management tools—you simply log in once and have access to everything. This seamless experience is SSO (Single Sign-On). It’s like having a universal key that opens all the doors to your workplace tools.
But how does SSO work?
This is where SAML (Security Assertion Markup Language) comes into play. Think of SAML as a trusted messenger between your login system (called the Identity Provider, or IdP) and the apps you want to use (called Service Providers, or SPs). When you log in through SSO, SAML securely sends a “proof” of your identity from the IdP to the app, confirming that you are who you say you are.
So, in short:
- SSO is the user experience: one login to access multiple apps.
- SAML is the behind-the-scenes protocol that makes that seamless experience possible by securely handling identity verification.
While SSO improves convenience, SAML ensures that everything stays secure and connected, allowing you to access everything without a second thought.
Does Enterprise SSO use other protocols?
Yes, in addition to SAML, OIDC is another protocol commonly used in Enterprise SSO scenarios. For example, in Logto’s enterprise connector, it supports both Microsoft Entra (OIDC) and Microsoft Entra (SAML).
Should I use SAML SSO?
If you’re selling to enterprise customers, it’s important to consider supporting SAML as early as possible. But don’t just focus on supporting the SAML protocol—think about the entire enterprise SSO authentication flow. Here are a few key scenarios to consider:
- Allow your clients to self-onboard and set up enterprise SSO.
- Ensure employees can automatically join the correct organizations in multi-tenant applications (this can be done with Just-in-Time provisioning and SCIM).
- Implement an end-to-end login flow that’s compatible with your consumer-facing login process.
Implement SAML and Enterprise SSO with Logto
Logto provides end to end enterprise SSO flows and supports multiple famous SAML connectors. It can be integrated into lots of common scenarios and you will need. Explore all of Logto’s features, from Logto Cloud to Logto OSS, on the Logto website.