What is the inherent weakness of the standard SAML Web Browser SSO profile, and why does TLS not fix it?

Question

Accepted Answer

Assertions are not cryptographically bound to the user's browser: they are bearer tokens, so anyone who steals one can use it to impersonate the user, and TLS only protects the transport between endpoints, not the assertion where it is exposed.

* Where a bearer assertion can be stolen: in the browser (XSS) and on the way to the SP (MITM). *
The flow hands the assertion to the browser (step 5) and lets the browser deliver it (step 6). Nothing in a bearer assertion proves that the party delivering it is the party it was issued to. TLS encrypts each hop, but:

At the browser, the assertion is in clear in the page the IdP returned. A cross-site scripting flaw lets attacker script read the auto-submit form and send the assertion away.
On the path to the SP, a man-in-the-middle who can terminate TLS (a forged or mis-issued certificate, a malicious proxy, a compromised network appliance) sees the assertion in clear and can replay it to the SP before the real one arrives.

In both cases the stolen assertion is just as valid as the original, because validity depends only on possession. That is identity theft through stolen assertions, and the reason the holder-of-key variant exists.
Go deeper:

OASIS: Security and Privacy Considerations for SAML V2.0 (PDF) — the threat analysis of bearer assertions and each binding.
 Single Sign-On: A Hacker's Perspective (MCH2022) — the vulnerabilities most often found in real SAML and OIDC deployments.