+ OpenID Connect first
+ maintained SAML library, patched
+ reject unusual message shapes
- your own XML signature checkSAML is the XML that logs you into almost every work app you own, and its signature lives inside the document it signs, like a notary stapling his stamp inside the envelope he's sealing. Ten years after a committee wrote it, researchers tested 14 SAML frameworks. 11 fell. And this week a Trail of Bits post calling it a fractal of bad design hit the front page of Hacker News. In three minutes: how the login dance works, where the signature hides, and why the fix everyone agrees on is a different protocol.
A security committee at Oasis merges four vendor XML formats into one. Universities adopt it first, then Okta builds a company on it, the fastest a committee document ever turned into revenue. You open the app. It has no idea who you are, so it bounces your browser to the identity provider, say your company's Okta. You log in there. Okta hands your browser a signed XML document that says who you are, and the browser posts it back. That document is the assertion. It names the user, and the signature sits inside it, pointing back at the assertion by its ID. And the whole thing rides through your browser, which is to say, through the user.
To check it, the app rebuilds the exact bytes that were signed. It cuts the signature back out, normalizes the whitespace and the attribute order, and hashes the result. That's canonicalization, and if the two sides disagree by a single byte, nobody logs in. A JSON web token does it differently. Header, payload and signature sit side by side with dots in between. Nothing to cut out first. Here's the crack. The code that checks the signature and the code that reads the username are often two different pieces. In 2012, a paper called On Breaking SAML showed you could move the signed assertion where the reader ignores it, and put a second one where it looks. Salesforce and Shibboleth were among the eleven that fell for it.
In 2018, Duo showed that a comment inside a username could make some libraries read only half the name, while the signature still checked out. In 2025, GitHub found two XML parsers inside ruby-saml disagreeing about the same document. Same bug, new decade. Trail of Bits calls it a fractal, because every level you zoom into has the same flaw. It's built on XML, the signature is enveloped, and real logins use maybe a tenth of the spec. And the top reply on Hacker News comes from the buyer. If you don't have SAML support, I can find a product that does. Both are true, which is the problem.
So, Monday. Ship OpenID Connect first, Fly and Tailscale sell to enterprises without SAML at all. If a customer forces it, use a maintained library, keep it patched, and reject messages that don't look like what Okta or Google send. Never write your own signature check. Verdict, under the hood. Revert. Almost 25 years, one bug class that never dies, and the fix everyone agrees on is a different protocol. Last Saturday I took apart passkeys, so tell me what to open up next in the comments.
Verdict: REVERT — same bug class since 2012 · the fix is OIDC
Sources
https://blog.trailofbits.com/2026/09/21/saml-a-fractal-of-bad-design/
https://news.ycombinator.com/item?id=49806335
https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/somorovsky
https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations
https://www.kb.cert.org/vuls/id/475445
https://nvd.nist.gov/vuln/detail/CVE-2017-11427
https://github.blog/security/sign-in-as-anyone-bypassing-saml-sso-authentication-with-parser-differentials/
And that's the diff for today. I'm Niko from Axrisi. Merge responsibly.
YouTube · thedailydiff.dev · forward this to the intern who deployed on Friday.