Introduction to SAML 2.0
Before we talk about what SAML is, let's talk about the problem it solves. Because that's the only way it'll actually make sense.
The problem: too many passwords
Imagine you work at a company that uses Salesforce, Slack, Jira, AWS, and a dozen other apps. Without any kind of federation, you'd need a separate username and password for each one. That's annoying for you, but it's a nightmare for IT.
Think about what happens when someone leaves the company. IT has to go disable their account in every single application. Miss one, and that ex-employee still has access to your production data. Now multiply that across hundreds of employees and dozens of apps.
The root cause? Each application is managing its own identity silo. There's no single source of truth for "who is this person and should they have access?"
So how do we fix this?
The idea: let one system handle identity
What if there was one central system that knew who everyone was? And what if all those other applications could just ask that central system, "Hey, is this person legit?" instead of managing their own user databases?
That's exactly what SAML does. SAML (Security Assertion Markup Language) is a protocol that lets one system vouch for a user's identity to another system.
There are two players in every SAML interaction:
The Identity Provider (IdP) is the system that knows who you are. This is usually something like Okta, Azure AD, or Ping Identity. It's where your company manages all employee accounts in one place.
The Service Provider (SP) is the application you're trying to access. Salesforce, AWS, Slack, whatever. It doesn't store your password. It trusts the IdP to verify you.
How the flow actually works
Let's say you want to log into Salesforce, and your company uses Okta as the IdP.
You go to Salesforce. Salesforce doesn't know who you are, so it redirects your browser to Okta. Okta shows you a login page (or skips it if you're already signed in). Once Okta confirms your identity, it creates a SAML Assertion, which is basically a signed XML document that says "this person is raj@company.com, they authenticated at 2:30 PM, and here are their attributes."
That assertion gets sent back to Salesforce through your browser. Salesforce checks the digital signature on the assertion to make sure it really came from Okta and hasn't been tampered with. If everything checks out, you're in. No Salesforce password needed.
The key insight: Salesforce never sees your password. It only sees a cryptographically signed statement from a source it trusts. This is what "federation" means. You're federating trust from one system to another.
Why this matters for security
When someone leaves the company, IT disables their account in the IdP. That's it. One action. Since every application relies on the IdP for authentication, that person instantly loses access everywhere.
You can also enforce MFA in one place (the IdP) and it applies to every application. You get centralized audit logs of who accessed what and when. And users only need to remember one password.
SAML vs. OIDC
You'll often hear SAML mentioned alongside OIDC (OpenID Connect). They solve the same fundamental problem but in different ways. SAML uses XML and was designed for enterprise web applications. OIDC uses JSON and was designed with modern apps and APIs in mind. Most enterprises use both, depending on what the application supports.
If you want to go deeper, I made a video series walking through the full SAML flow step by step: