Intermediate14 min

SAML 2.0

The XML-based federation standard that still runs most enterprise SSO.

By the end of this lesson, explain SAML SSO and when you'll meet it instead of OIDC.

How deep?

How the pieces actually move.

SAML 2.0 is the older, XML-based federation standard. It does what OIDC does — single sign-on across an identity provider and applications — but with signed XML assertions instead of JWTs. You will still meet it constantly: most enterprise SaaS SSO is SAML.

First, the whole system

First, see the whole system. Then we’ll open it up.

SP-initiated SSO

A user accesses the app (service provider), which redirects to the identity provider with an AuthnRequest.
The user authenticates at the IdP, which returns a signed SAML assertion.
The service provider validates the assertion and creates a session.

flowchart LR
  user[User] -->|1 access app| sp[Service Provider]
  sp -->|2 SAML AuthnRequest| idp[Identity Provider]
  user -->|3 authenticate| idp
  idp -->|4 signed SAML assertion| sp
  sp -->|5 create session| app[App access]

IdP and SP: Identity Provider (IdP) authenticates users and issues assertions. Service Provider (SP) is the app that trusts the IdP.

Operational complexity

SAML: ubiquitous enterprise support, mature, but heavyweight XML and browser-POST bindings, awkward for mobile and APIs. OIDC: lighter, API- and mobile-friendly, JSON. Choose SAML for enterprise SSO interop; OIDC for new apps and API access.

XML Signature Wrapping

Trigger: The SP validates a signature over one XML element but reads identity from another.
Symptom: An attacker injects a forged assertion the parser trusts.
Blast radius: Authentication bypass / impersonation of any user.
Mitigation: Use a hardened SAML library; validate that the signature covers the exact assertion consumed.

Deep dive: Privilege Escalation

How it connects

A new mobile app needs SSO. SAML or OIDC?

OIDC — it's designed for mobile and API clients; SAML's browser-POST bindings are awkward outside web apps.