What is SAML 2.0 and How Does It Work?
The basics of saml 2.0 for enterprise
Ever had that moment where you log into a work app and it just… works? No password prompt, no friction, just straight to your dashboard because you’re already signed into your corporate email.
What is SAML 2.0 and How Does It Work?
The basics of saml 2.0 for enterprise
Ever had that moment where you log into a work app and it just… works? No password prompt, no friction, just straight to your dashboard because you’re already signed into your corporate email. That’s usually saml doing the heavy lifting behind the scenes.
Security Assertion Markup Language (saml) is basically a way for different systems to tell each other, “Hey, I know this person, they’re cool to come in.” It’s an open standard based on XML that lets an Identity Provider (IdP) pass authorization credentials to a Service Provider (SP).
The jump from 1.1 to 2.0 was huge because it merged different standards into one cohesive framework. We use xml because it’s structured and readable by machines, even if it looks a bit clunky to us humans. According to Gartner, saml remains a cornerstone for web-based SSO because it decouples the authentication event from the application itself.
Healthcare: A doctor logs into the hospital portal and gets instant access to patient records, pharmacy apps, and billing without five different logins.
Retail: Store managers use one login to check inventory on a vendor’s site and then jump over to a logistics tracker.
Finance: Analysts access secure Bloomberg terminals and internal risk dashboards via a single corporate credential.
The whole dance relies on a trust relationship. The IdP (like Okta or Azure AD) is the source of truth that says who you are. The SP (the app you want to use, like Slack or Salesforce) trusts the IdP’s word.
Basically, the SP never sees your password. It just gets a signed digital “passport” from the IdP. This setup is great for security because if a employee leaves, you just disable them in the idp and they lose access to everything at once.
Next up, we’ll dig into how these assertions actually look under the hood.
Anatomy of a SAML Assertion
Before we move on, let’s actually look at the guts of that xml. It’s easy to talk about “tokens,” but seeing the tags helps make it real. A typical assertion has a few key parts: the Subject (who the person is), the Conditions (how long this is valid), and the AttributeStatement (the extra info like their email or role).
Here is a simplified version of what that “passport” looks like:
<saml:Assertion ID=”_a7b8c9…” IssueInstant=”2024-05-20T12:00:00Z”>
<saml:Issuer>https://idp.example.com/</saml:Issuer>
<!– The Subject tells the app WHO is logging in –>
<saml:Subject>
<saml:NameID Format=”urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”>
[email protected]
</saml:NameID>
</saml:Subject>
<saml:Conditions NotBefore=”2024-05-20T11:55:00Z” NotOnOrAfter=”2024-05-20T12:05:00Z” />
<!– AttributeStatement holds the “claims” about the user –>
<saml:AttributeStatement>
<saml:Attribute Name=”Role”>
<saml:AttributeValue>Admin</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<ds:Signature>…</ds:Signature>
</saml:Assertion>
That <ds:Signature> part at the bottom is the most important bit—it’s the digital seal that proves the idp actually sent this and some hacker didn’t just write it in notepad.
How the saml flow actually works
So, you’ve got the high-level idea of saml being a “passport,” but how does the actual handshake happen without things breaking? It’s basically a game of hot potato with xml tokens.
Most of the time, you’re dealing with two main flavors: SP-Initiated and IdP-Initiated. They sound fancy, but they just describe who starts the conversation.
In a typical SP-initiated flow (the most common one), the journey looks something like this:
The Request: You try to hit an app, say a private dashboard in your company’s analytics tool. The app realizes you aren’t logged in.
The Redirect: Instead of a login page, the app sends a SAMLRequest to your browser, which bounces you over to the idp (like Okta).
The Auth: You do your thing at the idp—password, mfa, maybe a hardware key.
The Token: Once the idp is happy, it hands your browser a SAMLResponse. This contains the “assertion”—the bit of xml we just looked at.
The Handover: Your browser posts that token back to the app’s Assertion Consumer Service (ACS) URL. The ACS is a specific endpoint on the Service Provider side (the app) that is built specifically to catch, parse, and validate the saml response. The app validates the digital signature, and boom, you’re in.
Security: Since the SP never sees your password, a breach at the app level doesn’t expose your corporate credentials.
User Experience: In IdP-initiated flows, users just click an icon in a portal (like a “Work Apps” dashboard) and get logged in instantly without even typing a url.
The Deep Linking Fix: One big pitfall is “Deep Linking.” If a user tries to access a specific report but the saml flow drops them on the homepage after login, it’s a huge pain. To fix this, we use a parameter called RelayState. It basically acts as a bookmark that the idp passes back to the sp, telling the app exactly where the user was trying to go before they got interrupted by the login screen.
Next, we’re gonna look at why ctos actually care about this stuff for their business.
Why ctos care about saml for ciam
If you’re a cto, you probably spend more time than you’d like worrying about “the enterprise wall.” You know, that moment where a huge potential customer says they love your product but won’t sign the contract unless you support their specific identity provider.
Honestly, saml is basically the ticket to the big leagues for any B2B startup. Without it, you’re stuck managing a million local passwords, which is a security nightmare and a massive drag on your support team.
Zero Trust and Security: You don’t want the liability of holding enterprise passwords. By using saml, you never touch the “secret,” you just trust the signed assertion.
Instant Offboarding: When one of your customers fires someone, they disable them in their idp (like Azure or Okta). Boom—they lose access to your app immediately. You don’t have to do a thing.
Compliance checkbox: Most big companies won’t even talk to you if you don’t have sso. It’s often a hard requirement for SOC2 or ISO 27001 audits.
Building a custom saml integration for every single customer is a trap. I’ve seen teams waste months trying to map custom attributes or debugging “Signature validation failed” errors. This is where an api-first platform like SSOJet saves your life. It handles the messy stuff like directory sync and certificate rotations, so your devs can actually build features that people pay for.
Now that we’ve seen why it’s useful, let’s compare it to the other big player in the space.
SAML vs OIDC: Making the right choice
So, you’re probably wondering—if saml is so great for enterprise, why does everyone keep talking about oidc? Honestly, it’s not about which one is “better,” it’s about what you’re trying to build and who’s using it.
Think of saml as that heavy, reliable master key for a corporate office building. It’s built on xml and is the absolute gold standard for big-box enterprise stuff. But if you’re building a sleek mobile app or a modern single-page web app, saml can feel a bit… clunky.
That’s where OpenID Connect (oidc) comes in. It sits on top of OAuth 2.0 and uses json, which is way lighter and easier for a javascript dev to handle than digging through xml namespaces.
Legacy vs. Modern: If you’re connecting to a 10-year-old active directory setup, you’re likely using saml. If you’re letting users “Sign in with Google” on an iPhone, that’s oidc.
Complexity: saml assertions can get huge. oidc uses small JWTs (JSON Web Tokens) that are easier to pass around in headers without hitting size limits.
Don’t get stuck in a “this or that” mindset. Most mature identity architectures use a bridge to handle both. Next, let’s look at some security best practices and how to handle common errors when things go sideways.
Security and Troubleshooting
Look, saml isn’t bulletproof just because it uses xml signatures. If you don’t validate the audience restriction, an attacker could reuse a token meant for one app to sneak into another.
Signature Validation: Always verify the full response and the assertion. skipping this is like checking a passport but not the hologram.
Clock Skew: Set strict NotBefore and NotOnOrAfter windows. Loose timestamps are an open door for replay attacks.
XXE Protection: You must disable external entity resolution in your xml parser. This prevents XML External Entity (XXE) attacks, where a malicious actor uses the xml file to trick your server into reading local files or hitting internal urls.
Common Troubleshooting Steps
Error
Likely Cause
Fix
Signature Validation Failed
Certificate mismatch or xml was altered in transit.
Check that the public key in your SP matches the IdP’s private key.
Audience Restriction Error
The ‘Audience’ in the xml doesn’t match your SP Entity ID.
Ensure your SP’s unique ID is correctly configured in the IdP settings.
Response Expired
The server clocks are out of sync.
Check the NotOnOrAfter tag and ensure your server uses NTP to stay on time.
Keep your metadata urls private and rotate certificates before they expire, not the morning after. Stay safe out there.
*** This is a Security Bloggers Network syndicated blog from SSOJet – Enterprise SSO & Identity Solutions authored by SSOJet – Enterprise SSO & Identity Solutions. Read the original post at: https://ssojet.com/blog/what-is-saml-2-0-and-how-does-it-work
About Author
