SAML explained simply: What is it and how it works

SAML (Security Assertion Markup Language) is a widely used authentication protocol that powers Single Sign-On (SSO) across many enterprise applications. If you've ever used one login to access tools like Salesforce, Zoom, or Google Workspace, you've benefited from SAML-based SSO.

In this guide, we'll explain how SAML works, why it matters for identity and access management (IAM), and how it compares to protocols like OAuth and OpenID Connect (OIDC). Whether you're building an app or evaluating SSO solutions, this article breaks down SAML in plain English, with real-world examples and best practices.

What is SAML?

SAML (Security Assertion Markup Language) is an open standard for authentication. At its core, SAML is what makes Single Sign-On (SSO) possible. It lets you log in once and access multiple apps without having to re-enter your username and password each time.

SAML is built on XML (Extensible Markup Language) and allows login information to be shared between two main players: an identity provider (IdP) (like Google or Okta) and a service provider (like Slack or Dropbox).

Before SAML came along, single sign-on (SSO) was tricky and mostly limited to apps within the same domain using browser cookies. SAML changed that by centralizing authentication with the identity provider. Now, users can log in once and access multiple, unrelated apps without juggling different usernames and passwords.

It’s a win for everyone:

• Users love it because there’s less password fatigue.
• Service providers love it because they don’t have to manage or store passwords, improving both security and user experience.

SAML benefits

SAML has become a popular choice for enterprises, and for good reason.

For starters, it streamlines the login experience. With SAML-based single sign-on (SSO), users only need to sign in once to access multiple apps. That means faster access, fewer credentials to remember, and less friction throughout the day.

On the IT side, it’s a win too: fewer forgotten passwords = fewer Help Desk tickets.

But the perks go beyond convenience; SAML also boosts security. Since login credentials are managed by the identity provider (IdP), the service provider doesn’t need to store any passwords at all. That reduces risk and exposure. Plus, identity providers are built for security. They can afford to invest in advanced protections like multi-factor authentication (MFA), threat detection, and other tools that would be difficult for individual services to implement on their own.

In short: better user experience, stronger security, and less hassle for everyone involved.

How SAML works

SAML enables different systems to securely share one key piece of information: who you are.

Rather than requiring you to log in to every web app separately, SAML enables a central identity provider (IdP) to handle the authentication and pass that info along to any application that trusts it (called a service provider, or SP).

Here’s the flow in action:

1. When a user tries to access an application (the service provider), that app doesn’t handle the login directly. Instead, it redirects the user to an identity provider (IdP), a centralized, trusted source responsible for authenticating the user.
2. The IdP verifies the user.
3. Once verified, the IdP sends the application a SAML assertion —a digitally signed message that confirms, “This user is authenticated and here are their credentials.”
4. The service provider reads this, validates it, and grants access.

Think of it like a trusted reference

Imagine you're applying to join a members-only club. Instead of proving your identity from scratch every time, you bring a signed letter of recommendation from a respected institution. The club doesn’t need to vet you; they just need to trust that the letter came from a verified source and that it checks out.

• The institution writing the letter = Identity Provider
• The letter of recommendation = SAML Assertion
• The club reviewing the letter = Service Provider

This whole flow lets you move smoothly between different “clubs” (apps) without constantly proving yourself. It’s efficient, secure, and lets everyone focus on what they do best.

What is SAML SSO?

SAML Single Sign-On (SSO) is a secure and efficient way to access multiple web applications with just one login. It uses the SAML protocol to let users authenticate once with a trusted identity provider (IdP)—and then access any connected apps without needing to re-enter credentials.

From a user’s perspective, it’s a huge time-saver. Instead of logging into every application individually, you just sign in once with your IdP. After that, you can launch any connected app, either by clicking its icon on a dashboard or simply navigating to its URL, and you’re in, no prompts, no passwords.

There’s also a clear cost benefit. With SAML SSO:

• Organizations don’t need to build and maintain their own login systems.
• Support teams spend less time (and money) on password-related issues.
• IT can streamline user provisioning and offboarding through a centralized IdP.

SAML vs OAuth

SAML and OAuth are both tools that manage access, but they do very different jobs under the hood.

• SAML is all about authentication: proving who you are.
• OAuth is focused on authorization: defining what you’re allowed to do.

Think of it like checking into a building with security:

• SAML is the badge at the front desk that verifies your identity and lets you through the main doors.
• OAuth is the keycard that controls which rooms or floors you can access inside the building.

So, SAML answers the question: “Is this person who they say they are?”

OAuth answers: “What can this person do now that they’re in?”

Why people confuse SAML with OAuth

A lot of people mix up SAML and OAuth, and this is thanks to OpenID Connect (OIDC).

OIDC sits on top of OAuth 2.0, and it adds authentication to a framework originally designed only for authorization. This combo is what powers things like “Log in with Google” or “Sign in with GitHub.”

So even though OAuth alone doesn’t handle login, OIDC extends it just enough to make it feel like it does. That’s where the confusion comes in: people see OAuth being used for login flows and assume it’s the same thing as SAML, which also handles authentication.

Let’s break it down:

‍

So when you’re logging into an app with your Google account, that’s not just OAuth: that’s OIDC + OAuth working together. And that’s what causes the mental mix-up.

When you’d use each one

• Use SAML when you need enterprise-grade single sign-on (SSO) for web apps, especially in corporate environments. It’s ideal for logging into services like Salesforce, Workday, or other apps via an identity provider like Okta or Microsoft Entra ID.
  
  • Example: Login to a web app using Okta as the trusted identity provider.
• Use OAuth 2.0 when an application needs secure, limited access to a user’s data or capabilities on another system, without accessing their login credentials. This is what enables features like a scheduling app adding events to your Google Calendar, or a photo editor uploading to your Dropbox.
  
  • Example: Allow a third-party calendar app to write to your Google Calendar, but not read your emails.
• Use OIDC (OpenID Connect) when you want to enable modern, consumer-friendly login experiences, such as “Sign in with Google” or “Log in with Facebook.” OIDC builds on OAuth 2.0 to add authentication (proving who the user is) while still allowing for secure delegated access to APIs.
  
  • Example: Let users log in to your app using Google.

In practice:

• SAML is often used in B2B and enterprise SSO environments
• OAuth is used for API access and delegated permissions
• OIDC is used for user authentication in modern apps, especially when supporting social logins or mobile-first platforms

All three protocols can coexist depending on your architecture. For example, your app might use OIDC for user login, then OAuth to access the user's resources, while integrating with SAML to support enterprise customers via federated identity.

A real-world example of SAML authentication flow

Let’s say your company uses an identity provider like Okta, and you need to access a service like Salesforce.

Here’s how SAML SSO makes that process seamless:

1. You open Salesforce: You type in the URL or click a shortcut, no login prompt appears yet.
2. Salesforce redirects you to Okta: Because Salesforce is configured to use SAML, it doesn't try to authenticate you directly. Instead, it sends a SAML request to Okta (your Identity Provider, or IdP).
3. Okta checks if you’re already signed in: If you’ve logged in recently, you won’t even see a login screen. If not, you’ll be prompted to enter your company credentials (maybe with MFA).
4. Okta sends a SAML response back to Salesforce: This response includes a SAML assertion, a secure, signed XML document that says, “Yes, this user is authenticated,” along with details like your name, email, and access permissions.
5. Salesforce verifies the assertion: It checks the signature, validates the details, and—if everything checks out—logs you in without asking for your username or password.
6. You’re in: You land directly in your Salesforce dashboard, all without entering credentials twice.

What’s happening behind the scenes

• Salesforce does not store passwords; instead, it relies on Okta to handle identity.
• The whole exchange is browser-based, using redirects and XML payloads.
• It’s secure, because the SAML assertion is cryptographically signed.
• It’s convenient, because one login gives you access to all SAML-enabled apps in your company’s ecosystem.

This flow is used every day by millions of users in companies that rely on tools like Slack, Zoom, Google Workspace, and others, all tied together by SAML behind the scenes.

Common SAML use cases

SAML is most commonly used in environments where centralized identity management and secure access control are critical. It shines in scenarios where users need to access multiple systems without managing separate logins.

Here are a few real-world examples:

• Enterprise SSO for employees: Employees log into various SaaS tools (like Salesforce, Slack, or Workday) using a single corporate identity provider such as Okta, Microsoft Entra ID, or Google Workspace.
• Campus-wide login systems in education: Universities allow students, faculty, and staff to access learning platforms, library systems, and internal portals through a single campus-issued login.
• B2B SaaS platforms offering SSO to customers: Software companies enable enterprise clients to configure their own SAML-based SSO connections, so employees can log in using their organization's identity provider.

These use cases highlight SAML’s strengths: scalability, security, and ease of access across large organizations and federated environments.

Limitations of SAML

While SAML is powerful and widely adopted in enterprise environments, it’s not without drawbacks, especially as modern apps shift toward mobile, API-first, and consumer-facing architectures.

Common limitations include:

• Not mobile-native: SAML was designed for traditional web apps and doesn’t play well with native mobile apps or single-page applications (SPAs).
• XML-based: It relies on XML, which is more verbose and complex than modern JSON-based protocols like OpenID Connect.
• No API authorization support: Unlike OAuth, SAML doesn’t natively handle delegated access to APIs or granular permission scopes.
• Configuration-heavy: Setting up SAML requires precise coordination between the identity provider (IdP) and service provider (SP), including certificate management, endpoint matching, and attribute mapping.

For modern or mobile-first apps, OIDC or OAuth 2.0 may be a better fit. But for enterprise SSO—especially in environments with strict compliance requirements—SAML remains a trusted standard.

SAML tutorial

Setting up SAML from scratch (and maintaining it) can be complicated.

WorkOS makes it way easier by handling the protocol plumbing and offering a developer-friendly API.

Here is how to add SAML Single Sign-On to your app using WorkOS:

1. Sign up for a WorkOS account.
2. Set up a SAML connection to the identity provider of your choice. Find detailed instructions for each provider here.
3. Follow the quickstart for the programming language you use:
   
   • Quickstart if you want to use AuthKit, a fully customizable login box powered by Radix.
   • Quickstart if you want to use your own login box.

That’s it, you just added SAML SSO to your app.

With this one integration, you can now support dozens of identity providers.

And if you want your customers to configure their own identity providers, use the Admin Portal, a self-serve UI to onboard customers without the back-and-forth.

SAML FAQ

What is SAML 2.0?

SAML 2.0 is the current version of the Security Assertion Markup Language, a standard for enabling Single Sign-On (SSO). It allows identity providers to securely pass user authentication data to service providers, so users can log in once and access multiple apps. SAML 2.0 supports cross-domain SSO, stronger security, and is widely used in enterprise environments.

‍

How does SAML work in simple terms?

SAML acts like a digital trust handshake between your identity provider (like Okta) and your application (like Salesforce). You log in once with the IdP, which sends a SAML assertion to the service provider saying, “This user is authenticated.” The app trusts that and logs you in automatically.

‍

Is SAML the same as SSO?

Not exactly. SAML is a protocol that enables SSO, but SSO can also be implemented using other protocols like OpenID Connect (OIDC) or Kerberos. So, SAML is one way to achieve SSO, not the only way.

‍

What’s the difference between SAML and OAuth?

SAML handles authentication (proving who you are), while OAuth handles authorization (what you’re allowed to do). OAuth is often used for granting apps access to user data without sharing passwords.

‍

What is a SAML assertion?

A SAML assertion is a secure, signed XML document that contains the user's identity and authentication status. It’s issued by the identity provider and consumed by the service provider to grant access.

‍

Is SAML still used today?

Yes. While newer protocols like OIDC are common in modern, consumer-facing apps, SAML is still the standard in many enterprise environments. It's widely supported by major IdPs and SaaS platforms.

‍

Is SAML secure?

Yes, when configured correctly. SAML uses cryptographic signatures and encryption to ensure assertions can’t be tampered with. Since it eliminates password storage on service providers, it also reduces phishing and credential theft risks.

‍

What are alternatives to SAML?

Alternatives include:

• OpenID Connect (OIDC): better for mobile and modern web apps
• OAuth 2.0: for delegated access to APIs, not full user authentication
• LDAP / Kerberos: typically used in legacy or on-prem systems