The incredible overengineering of the XML signature specification is certainly to blame for this recent SAML verification vulnerability (from the same site): https://news.ycombinator.com/item?id=41586031
What I have in mind - I'd say only very small population understand that OIDC / Oauth(orization) is about granting access to a service to access your data. Meaning once you have approved service (lets say Dropbox), now Dropbox can access your data on your google account (this of course depends what exactly dropbox asked and if you clicked on "approve", but most people do click as they want to login to Dropbox via their Google account).
SAML is better, as it can be defined at Google side what data is being sent to DropBox when Single Sign On happens and DropBox cannot access your google data as it sees fit.
SAML ain't perfect either because there's no practical way to "sign me out everywhere"
> As well in "HTTP Redirect Binding" or "HTTP POST Binding", The RelayState value MUST NOT exceed 80 bytes
From https://docs.oasis-open.org/security/saml/v2.0/saml-bindings...
At FusionAuth, we have an open issue for this: https://github.com/FusionAuth/fusionauth-issues/issues/2467 which you can read for more details.
SAML is full of these kinds of gotchas. We have an open source library which provides Java SAML bindings: https://github.com/FusionAuth/fusionauth-samlv2
OIDC is far preferable to SAML, but the last time I touched this, half the reason why customers preferred SAML was because their IdP supported SCIM but only for SAML applications.
Is it just me or is anybody else going 'the fuck did I just read?' here? It's... incredibly condescending?
> You care about supporting SAML because your customer wants your product to support SAML. This is sound reasoning on your part. But why does your customer want SAML support?
> One click to login: why your users like SAML
What? No, the users don't know about SAML.
Anyways, no, users don't like SAML. OIDC has a much nicer UX.