Prerequisites — complete these first.
- [OAuth 2.0 and Federated Login](/lessons/oauth-federated-login) — SAML solves the same delegation problem as OAuth but with completely different machinery; you need the OAuth mental model to understand what changes.
- [Session Management and JWT Security](/lessons/session-jwt-security) — a successful SAML login mints a session or token; you need to know what that artifact is and how it can be forged.
- [XXE and Deserialization](/lessons/xxe-and-deserialization) — SAML is XML-based; the parser-gap intuition from that lesson directly predicts the main attack here.
If you have not completed all three, do so before continuing. The attacks in this lesson will not make sense without that foundation.
Course position: This lesson is not a direct continuation of Lessons 1–2 in the Sessions, SSO & Access Control category. It sits after the full Authentication & Credentials category, OAuth 2.0, and the XXE & Deserialization lesson. If you arrived here from the category tile, confirm all three prerequisites above are complete before continuing — there is a substantial gap in the curriculum between Lesson 2 and this lesson.
You have already studied [OAuth 2.0 and federated login](/lessons/oauth-federated-login) — the token-and-redirect way to delegate authentication, secured by redirect_uri, state, and PKCE. *(Quick recall: the user clicks "Log in with Google," is redirected to Google with a state value your app tracks, approves access, and is sent back with a short-lived code that your app exchanges for a token via a direct back-channel call. The redirect_uri stops the code from being delivered to the wrong server; the state prevents request forgery. That redirect-and-token model is the baseline you are now extending to XML.)* This lesson covers the other federation protocol you will meet constantly, the one that dominates the enterprise: SAML (Security Assertion Markup Language).
Authorised targets only. The active techniques here — tampering with an assertion, wrapping or stripping a signature, replaying a response — are attacks on an authentication system. Exercise them only against a lab you own (a local SimpleSAMLphp or Keycloak Identity Provider + Service Provider in Docker, or a PortSwigger SSO/SAML lab) or an enterprise SSO you are explicitly authorised to test. Review [Hacking Ethics and Authorization](/lessons/hacking-ethics-and-authorization) first. NovaCart ships an OAuth-style "Log in with Google" button for contrast but does not implement SAML, so the practical uses an external lab.
The core idea is the same as OAuth: delegate authentication. A central Identity Provider (IdP) authenticates the user once, and each application — the Service Provider (SP) — trusts a signed statement from that IdP instead of handling passwords itself. One corporate login, dozens of apps.
What is different is the machinery — and the machinery is where the bugs live.
- OAuth/OIDC is JSON and JWT, secured by
state/redirect_uri/PKCE and a back-channel token exchange. - SAML is XML, secured by an XML digital signature over an assertion. There is no
stateparameter; the entire integrity guarantee is that signature — and almost every SAML vulnerability is a failure to validate the signature over the right bytes.
If the [XXE and deserialization](/lessons/xxe-and-deserialization) lesson taught you that XML is deceptively complex and that the gap between what a parser validates and what the application reads is dangerous — you already have the right instinct. SAML's signature attacks are exactly that gap, turned against login.
The parser-gap idea in one sentence (a reminder, not new content): an XML document can contain two structurally valid elements with the same name; the code that validates a signature over one of them and the code that reads the result may silently end up working on different elements. In SAML, the validated element carries a legitimate signature and the consumed element carries the attacker's forged identity — that is the entire XML Signature Wrapping attack in one sentence.
In this lesson you will:
- Place SAML against OAuth and learn the actors (User-Agent, Service Provider, Identity Provider) and the SP-initiated vs. IdP-initiated flows.
- Learn assertion anatomy —
Subject/NameID,Conditions/AudienceRestriction,Issuer,Signature— and what an XML signature actually covers. - Meet the attack families: XML Signature Wrapping (XSW), signature stripping, audience/recipient confusion, replay, and comment injection.
- **Capture and Base64-decode a real
SAMLResponse** on a lab and locate the assertion and its signature. - Take away the durable fix: validate the signature over the consumed assertion, against a pinned IdP certificate, and enforce audience and time.
Click Continue when you are ready.