SAML is the open standard protocol that lets identity providers talk to service providers using XML messages that would make a grown developer cry. Released in 2002, SAML 2.0 is still the current standard because apparently the enterprise world believes if something isn't broken, don't fix it. Even if "not broken" means debugging XML namespace issues at midnight. The OWASP SAML Security Cheat Sheet documents all the ways this can go wrong, while security considerations from the official spec read like a horror novel for authentication engineers. As of October 2025, Security Boulevard reports that SAML continues to face new authentication bypass vulnerabilities, making security updates more critical than ever.
The Three Players in This XML Theater
There are three pieces that have to work together, and when they don't, you'll know it:
Identity Provider (IdP): The thing that actually checks if your password is right. Examples include Microsoft Entra ID (which works great if you love Microsoft), Okta (expensive but actually works), and Ping Identity (for when you need government-grade paranoia). OneLogin's SAML best practices and Axon's implementation guide explain how these actually work when properly configured.
Service Provider (SP): The app you actually want to use, but it won't let you in until the IdP vouches for you with a digitally signed XML document. Could be Salesforce, could be your company's homegrown expense system from 2003.
User Agent: Your browser, which gets bounced around like a ping pong ball between the IdP and SP until everyone agrees you're allowed to look at spreadsheets.
The Authentication Dance (When It Works)
The SAML SSO process looks simple on paper:
- You click the app: "I want to check my expense reports"
- App panics: "I don't know who you are!" Redirects you to the IdP with a SAML AuthnRequest
- IdP checks: "Oh, you again. Password? MFA code? Blood sample?"
- IdP signs off: Creates a digitally-signed XML assertion that basically says "This person is legit"
- Browser delivery: Your browser carries this XML love letter back to the app
- App validates: Checks the signature, reads the XML, and (hopefully) lets you in
When this works, it's beautiful. When it doesn't, you get error messages like "SAML Response signature validation failed" and you start questioning your life choices. WorkOS's debugging guide and Microsoft's troubleshooting docs will become your new best friends during those 3am debugging sessions.
The XML Nightmare Behind the Scenes
SAML communicates entirely through XML messages, because apparently in 2002 someone thought "You know what authentication needs? More angle brackets!"
There are three types of assertions floating around:
- Authentication Assertions: "Yes, this person typed in a password 5 minutes ago"
- Attribute Assertions: User details like name, email, whether they're in the "can-see-payroll" group
- Authorization Assertions: "This person is allowed to look at these specific things"
The messages get transported via HTTP POST (most common), HTTP Redirect (for simple requests), or SOAP (if you hate yourself). Most web apps use HTTP POST because it's the least terrible option. Wikipedia's SAML 2.0 page explains these transport methods, while Stack Overflow's debugging discussions show what happens when XML signatures break.
Despite being XML-based in a JSON world, SAML is still everywhere in large enterprises because migrating enterprise authentication is like performing heart surgery on a patient who's running a marathon. Scalekit's security vulnerability handbook explains why this complexity creates so many security pitfalls.
