Comment by unscaled
It's not just shitty implementations here. The designers of SAML and XMLDSig cannot just blame the developers for implementing their "perfect" spec incorrectly.
The blog post above details exactly why XMLDSig can only be implemented securely, if you explicitly make an effort to ignore the spec. When following the specification leads to insecure implementations it's the spec that's shitty, and the spec authors should carry the blame.
The Open ID spec isn't great either and has its own share of issues, but in most scenarios, it doesn't rely on signature validation. If you only use the authorization code flow, breaking the ID token signature becomes ineffective, since the attacker still needs a valid authorization code from the IdP for this attack. If you restrict your implementation to what is allowed in OAuth 2.1 [1] or follow OAuth Best Practices [2], you can implement Open ID Connect pretty safely, as they eliminate the implicit grant and introduce PKCE.
I sure wish the OpenID foundation would cut all the unnecessary bloat in their spec(namely the ID Token, Implicit and Hybrid Flow and unnecessarily client-side token validation rules) and leave it as just a simple extension to OAuth 2.1 that specifies a few extra parameters and a User Info Endpoint. But if we have to leave with this over-engineered spec, I can still trust that implementations of OIDC would fail less horribly than SAML.
> It's not just shitty implementations here
I agree 100% the spec is shitty, but on top of it,some of the implementations are really weird beyond the spec. there was a prominent c library for it that (last i checked) in the default config added a custom hmac signature version where the hmac key is embedded in the attacker control document, and also hooked into the the system web pki, so if the provided key doesnt match, it will test if the doc was signed by a tls key from any website in the world.