SAML vs SSO: Are They The Same Thing?

SAML and SSO are not the same thing. However, many people use these terms interchangeably. The confusion stems from the fact that SSO can be implemented by SAML and it’s not uncommon to see the process referred to as SAML SSO. SAML, however, is just one of the protocols that enable SSO — one other popular one is OpenID Connect.

In this article, we will dive deeper into what SSO and SAML are in order to differentiate them and then explain exactly how SAML enables SSO.

Which is right for you + what are they?

SAML (Security Assertion Markup Language) is an XML-based open standard for exchanging authentication and authorization data between parties, like an identity provider and a service provider.

SSO (Single Sign-On) allows a user to log in once and access multiple apps. SAML is one of the standards used to enable SSO.

Use SAML SSO if you’re building an enterprise app and want to support SSO — it’s widely popular among enterprises and most corporate Identity Providers support it.

Use other protocols like OpenID Connect for consumer-facing apps especially if you want to support SSO via social accounts like Facebook and Google or are building mobile or Single Page Apps which SAML struggles with.

What is SSO?

SSO is a user authentication method that allows a user to authenticate once from a single place and access multiple applications.

The beauty of SSO lies in its convenience. It eliminates the need for users to remember multiple authentication factors.

IT admins also love it because it means not having to manage account credentials for each app used within the company or dealing with reset requests when employees inevitably forget their login details.

How SSO works

SSO is enabled by identity providers like Active Directory (AD) or cloud-based solutions like Microsoft Entra and Okta, which centralize user credentials and profile information.

When a user attempts to access your app that’s integrated with an IdP, instead of prompting the user to log in, you redirect the authentication request to the IdP.

Upon receiving the authentication request, the IdP checks if the user is already authenticated. If not (i.e., this is their first access attempt or their session has expired), the IdP prompts the user to log in.

Once the user successfully authenticates, the IdP generates an authentication token, which is a secure, digital proof of the user's identity and may potentially contain their authorization information and send it back to you.

You then validate the authentication response and grant access to the user if the token is valid and they have permission.

With the user now authenticated, if they attempt to access another service or app within the same SSO ecosystem (i.e., connected to the same IdP), the IdP bypasses the need for the user to re-authenticate.

This is Single Sign-On — signing in once and getting access to multiple apps.

What is SAML?

SAML is one of the protocols that enable SSO.

It’s an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). It provides a detailed framework for how SSO can be implemented, specifying precisely how identity data should be structured, exchanged, and secured between IdPs and SPs. It defines:

• XML assertions: These are XML documents that IdPs generate to communicate the identity and attributes of a user to an SP. They contain information about how and when the user was authenticated, user data like email addresses, roles, or group memberships, and may also contain authorization data indicating what resources the user is authorized to access.
• Binding for exchanging messages i.e. the HTTP redirect binding often used to send authentication requests from SP to IdP and HTTP POST binding for sending responses from the IdP back to the SP.
• Security measures: SAML messages and assertions can be digitally signed using XML Signatures. Sensitive portions of the SAML assertion can also be encrypted to ensure that only the intended recipient (the SP) can read it.

How SAML works

A SAML authentication flow can either be SP-initiated or IdP initiated.

An SP-initiated flow typically follows these steps:

• The user tries to access a service or resource on the SP's site.
• The SP redirects the user to the IdP with a SAML Authentication Request.
• The user logs in at the IdP’s login page. The IdP authenticates the user.
• Upon successful authentication, the IdP generates a SAML assertion containing the user's identity and possibly authorization information.
• The IdP sends the SAML assertion back to the SP, typically through the user's browser using the HTTP POST binding.
• The SP processes the SAML Assertion, validates it, and then grants or denies access to the user based on the information in the assertion.

In an IdP-initiated SSO, the process starts when the user is already logged in at the IdP and attempts to access a service directly from the IdP's portal. Here’s how it works:

• The user selects a service or resource from the IdP's portal or dashboard, which they wish to access.
• The IdP creates a SAML assertion based on the user's current authenticated session. This assertion includes the user's identity and any relevant attributes.
• Without the need for an authentication request from the SP, the IdP sends the SAML assertion directly to the SP.
• The SP receives the SAML Assertion, processes it, validates the assertion's authenticity and integrity, and then extracts the user's identity and attributes.
• Based on the information in the assertion, the SP grants or denies the user access.

How does SAML enable SSO?

SAML enables SSO by providing a common protocol for exchanging authentication data between IdPs and SPs.

When a user logs in through an IdP, multiple SPs can understand the authentication assertions generated by the IdP provided it follows the SAML protocol. Users don't need to repeatedly enter credentials for each service; the IdP can send their authentication status in assertions that all connected apps understand.

Are there other options to enable SSO?

While SAML is a popular choice for enabling SSO, there are other options like:

• OpenID Connect (OIDC): Built on top of the OAuth 2.0 protocol, OpenID Connect provides SSO for a wide range of apps including web, mobile, and APIs.
  
  It uses access tokens (in the form of JWTs), making it super lightweight compared to SAML which uses verbose XML assertions.
  
  It’s commonly used to enable SSO through social sites like Google, Facebook, and Apple.

• Kerberos: This isn't really an SSO protocol though it does act as one if all apps are inside the same enterprise network. It’s commonly used by enterprises as part of their Active Directory services for authentication.

FAQs

Are SAML and SSO the same thing?

No, they are not the same. SAML is an authentication protocol, while SSO is a feature enabled by SAML. SAML allows service providers and identity providers to communicate and exchange identity data.

Should you support SAML SSO?

If you’re building enterprise apps, you should support SAML SSO. It’s a widely used protocol, particularly within enterprise environments. Supporting it means aligning with a standard that many organizations already trust and use. This not only broadens your compatibility with various enterprise Identity Providers (IdPs) but also makes your SaaS more appealing to a larger segment of potential enterprise customers.

What are SSO and SAML used for?

Both SSO and SAML are used to simplify user authentication. SSO is an umbrella term that refers to users authenticating once and logging in to multiple apps while SAML is one of the protocols that enable SSO.

Next steps

Most businesses use SSO to grant their employees access to tons of apps they need for work. If you're looking to get these businesses on board, your app needs to support SSO just like the other apps they use.

Starting with SAML SSO is a smart move since it's what most corporate IdPs use, but you may also want to support OIDC which is also popular among enterprises.

And while you could build these SSO integrations from scratch, it could tie up your engineering team for weeks if not months. If you’d rather spend that time building your core product instead, consider using WorkOS. With just a few lines of code, you can connect to any SAML or OIDC-compliant identity provider and get enterprise-ready in no time.

• Get started fast: With SDKs in every popular language, and Slack-based support, you can implement SSO and connect to OAuth providers in minutes rather than weeks.
• Support every protocol: With OAuth 2.0 integrations of popular providers like Google and Microsoft, compatibility with every major IdP, and full support for custom SAML/OIDC connections, WorkOS can support any customer out of the box.
• Avoid the back-and-forth: WorkOS’s Admin Portal takes the pain out of onboarding your customers’ IT teams and configuring your app to work with their identity provider.
• Pricing that makes sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard — whether they bring 10 or 10,000 SSO users to your app.

Explore Unified SSO by WorkOS.