We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 5-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
SAML was published in 2005, an eternity in tech years. Yet it remains the dominant protocol for enterprise SSO and identity federation. If your SaaS application wants to sell to enterprises, you will need SAML support. Salesforce, Workday, ServiceNow, Atlassian, Slack, Zoom, they all speak SAML. Enterprise IT departments have spent years building their identity infrastructure around it, and they are not switching because a developer finds XML verbose.
Okta's 2023 data showed that SAML still handles the majority of enterprise SSO integrations among their customer base. New integrations increasingly use OIDC, but the installed base of SAML is enormous and will take a decade to decline.
SAML defines how an identity provider (IdP) can send authentication assertions to a service provider (SP). The user authenticates once at the IdP, and the IdP generates a signed XML assertion that the SP can verify and trust, without the user's password ever touching the SP.
SAML's most common flow is SP-initiated login. The user starts at the app, gets redirected to the IdP, authenticates, and comes back with a signed assertion.
Here is the step-by-step process. The user opens app.example.com. The SP has no session for this user, so it generates a SAML AuthnRequest XML document containing the SP's entity ID, the requested authentication context, and a unique request ID. The SP encodes this request and redirects the browser to the IdP's SSO URL. The user authenticates at the IdP (password + MFA). The IdP generates a SAML Response containing a signed Assertion with the user's identity (NameID), attributes (email, groups, roles), an audience restriction (this assertion is only for app.example.com), and a validity window. The IdP signs the entire Response with its private key and returns it to the browser as a hidden form field that auto-submits via POST to the SP's Assertion Consumer Service (ACS) URL. The SP validates the XML signature, checks the audience and validity window, extracts user attributes, and creates a local session.
The browser is the courier throughout. The IdP and SP never communicate directly. This is a deliberate design choice that avoids the need for the IdP and SP to have network connectivity to each other.