1. It has the ill-conceived "alg": "none". But this feature made breaking JWT so easy and low stakes, that many libraries have removed this feature completely, or just disabled it by default.

Modern RFCs that mandate JWT use in servers (e.g. RFC 9068) often explicitly forbid this, and the latest BCP for JWT (RFC 8725) recommends that libraries only accept or generate tokens with "none" when the user _explicitly_ requests that. And yet, we're still seeing "alg": "none" vulnerabilities even to this day. I'm not sure if it made sense to support "alg": "none" in the first place, but if we ended up doing that, the RFC should have been much more strict about this.

2. The other issue is mixing up asymmetric and symmetric encryption. You can't embed the HMAC password directly in the user-generated message; but if the library is not built securely, it would just treat the public key itself as the HMAC key when it gets an HMAC alg in the header. This makes forging tokens quite trivial if the library is misconfigured.

JWT is not nearly as bad SAML and its designers learned some important lessons (simpler base format, no canonicalization or embedded signatures), but this is still a design-by-committee standard that didn't properly involve. The full JOSE standard (including JWA) is even worse, but fortunately JWA doesn't get used a lot.

Specifying the algorithm in the attacker controlled document is a bad design imo.

Still i feel like SAML is much worse. JWT has a few rough edges, but SAML its like everything.

Who do you think would host the "federated login" system that would replace the major authentication companies?

You can already stand up a SAML or OIDC provider using OSS and run the IdP for your company. I have many customers that do! And you bet we still charge them for SSO, and that they're every six months asking how bad the migration to a "big auth company" would be.

From vague memory, the other stuff in OpenID Connect was layered over the original OpenID identity verification part.

The DSIG problems are wildly worse than syntax! There's a document object model to contend with, along with invariably-fatal parser differential bugs, and that's before you confront the one global C implementation that almost every DSIG implementation ends up relying on.

XML is deceptively simple-seeming, but it's not simple at all. JSON isn't actually trivial, mind you, but by comparison to XML, ASN.1/DER, etc, JSON is trivial.

The only reason to prefer ASN.1/DER here is that the likelihood of very badly broken libraries that fail to validate signatures becomes comparable to the same for x.509/PKIX certificates: fairly low due to the need for a whole ASN.1/DER ecosystem. It's the must-be-this-tall-to-ride effect.

To be fair to OASIS, in 2002 XML was textual and simple-seeming. It was the obvious choice. It must have seemed brilliant. They didn't know it would turn out badly.

Even with JSON you need solid decoders, excellent libraries, and you'll still want a JSON Schema and tooling.

We can’t change the past anyway, but ‘considering SAML harmful’ today may be the most reasonable position to take.

The OIDC specification is pretty hand-wavy about how to prevent this attack as well. So don't assume all OIDC implementations do.

I think you're drastically overstating Tailscale's share and ubiquity in the market. Maybe it's heavily represented in tech companies or those in The Valley but among rank and file normal companies not dominated by developers, they've never heard of Tailscale

This isn't strictly a limitation of OIDC, but I do see this issue more often with OIDC implementations. With IdP-initiated flows, the app doesn't need to know who's in my IdP ahead of time.

But it turns out, all the major IDPs support OIDC now. It's a non-issue.

I used to maintain a legacy public IdP with a bespoke saml implementation that predated almost anything and was a nightmare to work with. I always wanted to migrate to one login. Luckily I left that job before embarking in such a nightmarish project.

In SAML you sign a (potentially attacker controlled) subset after normalization. So a lot of saml bugs come down to the attacker adding things that aren't covered by the signature. Sometimes this means appending or prepending stuff, but my favourite is adding comments which can alter the interpretation of the xml document (as it splits text nodes) but doesn't alter the signature.

You would be shocked (or, if you’re in the security space at all, not even remotely shocked) to learn that a comical number of SAML implementations verified the signature and then just treated the whole doc as if it was trusted, even if the signed part had nothing to do with the document as a whole.

So it is possible to have an XML signature that points to an element that does not include some important piece of data.