IdP, SP & the Assertion-Based SSO Flow
Two Roles: Identity Provider & Service Provider
SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication/authorization data. The Identity Provider (IdP) authenticates the user and issues signed assertions; the Service Provider (SP) — the app the user wants — trusts and consumes those assertions rather than authenticating the user itself. This federation lets identity established in one domain be recognized in another without a shared user database.
Assertions & Signing
An assertion is an XML document with statements about a user — identity (via NameID, in an agreed format like email or a persistent opaque ID) and attributes. It's digitally signed by the IdP so the SP can cryptographically verify it actually came from the trusted IdP and wasn't tampered with — the SP validates using the IdP's public key/certificate, typically obtained via metadata exchange.
SP-Initiated vs. IdP-Initiated Flow
SP-initiated: user → SP login → redirect to IdP → auth → assertion POSTed → SP's ACS URL
IdP-initiated: user → IdP portal → clicks app tile → assertion POSTed → SP's ACS URLBoth are valid within the spec, differing only in where the user starts. Either way, the browser carries the assertion (commonly via HTTP-POST binding, an auto-submitting form) to the SP's Assertion Consumer Service (ACS) URL, where the SP validates it and establishes a session.
Keep your own version of these notes — editable, searchable, and organised by your stack.
Start free