SAML 2.0 is the older, XML-based standard for enterprise single sign-on. It's heavier than OIDC, harder to debug, and full of cryptographic edges where implementations have repeatedly gone wrong — but it's still the price of admission for B2B SaaS deals with large customers running Active Directory Federation Services (ADFS), Ping, or Shibboleth. You don't pick SAML; you support it.
← Back to SecurityAuthnRequest (XML) and redirects them to the IdP.Audience, NotOnOrAfter, InResponseTo, then issues its own session.The famous SAML attack class. The assertion is signed, but the verifier looks at one part of the document and reads identity from another. Carefully crafted XML can have a valid signature on a benign element and an attacker-controlled identity elsewhere — the parser and the verifier disagree.
Fix: use a vetted SAML library (OneLogin's, ITfoxtec, OpenSAML, SAPI). Don't parse SAML XML by hand. Configure the library to canonicalize, then verify, then read claims — and verify that the identity it reads is from the signed portion.
An assertion intended for one SP can be replayed at another if the receiver doesn't check Audience. Always verify Audience matches your SP entity ID exactly.
InResponseToSP-initiated flows must verify the assertion's InResponseTo matches the original AuthnRequest ID stored in the user's session. Without it, a captured assertion can be replayed at the user's browser to log them in as the original user — or worse, to a different SP.
NotBefore and NotOnOrAfter windows must be honored. Some libraries default to a generous skew (5+ minutes) for "compatibility." Tighten it; an old assertion is a useful tool for an attacker.
Without an AuthnRequest the SP started, you can't bind the assertion to a session. Some implementations allow IdP-initiated flows by accepting any unsolicited valid assertion — this opens replay and CSRF-flavored attacks. Disable unless required; if required, generate a session token strictly tied to the assertion's instant.
| SAML | OIDC | |
|---|---|---|
| Format | XML, signed | JSON, signed |
| Mobile / SPA fit | Awkward | Native |
| Tooling | Heavy, library-required | Many libraries, simple flows |
| Discovery | Metadata XML exchange | /.well-known/openid-configuration |
| Where you'll meet it | Big enterprises, ADFS, Shibboleth, education | Everything new |
| Implementation risk | High — XML signature pitfalls | Lower with vetted libraries |
Recommendation for B2B SaaS: support both. Implement OIDC first (most modern customers); add SAML when an enterprise deal demands it. Use a service like WorkOS, SSOReady, Cloudflare Zero Trust, Okta SSO Service to abstract SAML's pain — they translate every customer's IdP into a clean OIDC-style API for your app.