SAML signs "XML Documents". It does not sign the specific bytes of a document, you have to perform a transform to get the "canonical" version of the document and that's what you perform cryptography on. This creates a large surface for different implementations to be incompatible, subtly, but more importantly it creates a surface area for the nastiest bugs in authentication - When the sender and receiver have different interpretations of the message.

This has lead to things like popular SAML parsers that do not even attempt to validate the signature. For examples of how this has gone badly wrong, see https://workos.com/blog/fun-with-saml-sso-vulnerabilities-an... .

The short version of why SAML is bad is because it’s based on XML. This means that SAML is not only subject to the usual vulnerabilities that you’d expect, but also XML vulnerabilities!

A slightly longer explanation is that SAML is based on a garbage cryptographic signature standard called “XML-DSig” which, among other issues, allows for partial signatures and stores the signature inside the XML element that it signed.

Honestly, SAML is something of an info hazard. I don’t recommend learning more about it. But if you really want to, this blog post goes into more detail: https://dev.to/workos/fun-with-saml-sso-vulnerabilities-and-...

It's just riddled with vulnerabilities but most of them are now well known and mitigated.

OpenID was meant to be the successor but popularity wise SAML is still the champion with enterprises.

SCIM doesn't really have a successor afaik. Azure AD I think doesn't do password sync, I am not sure who twisted Okta's hands to get this implemented.

It's all the same thing with a different flavor

You have a signing authority and it liaisons access. Though it does go in the wrong direction a little bit with SAML