Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • I have to know. Is this a play on the ever-so-popular https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
    by bigquama
  • SAML is even worse than the article describes, problems like needing to check what the signature actually signs. But I'm optimistic about the future, instead of relying on libraries that do a lot, such as general xml parsing, we can support a subset of SAML and only the dialects of the top ~10 providers. Extreme niche providers can be added ad-hoc and only if the deal size makes it worthwhile.
    by arpinum
  • SAML is XML era legacy so mostly ugly but it's just the form of it. But all the security problems come from XMLDSIG which is just the worst signature scheme ever designed. So much complexity for so few to deliver. Just sign a bunch of bytes.
    by bdauvergne
  • A fair criticism of the article is that it lists SAML's vulnerabilities but doesn't do the same comparison for OIDC. OIDC has its own problems too: JWT algorithm confusion, none algorithm attacks, missing audience checks, and bugs in JOSE libraries
    by tehnoslow
  • SAML sucks, but it still has a bunch of features for its specific narrow enterprise SSO use-case that OIDC lacks - most notably IdP-initiated flow. OIDC is a constellation of specs with inconsistent support across products, whereas the commonly-implemented subset of SAML is more-or-less stable in its mediocrity.

    OIDC will eventually displace SAML, but if you're selling to enterprises you should really support both. Both will pale compared to the amount of time you spend dealing with SCIM inconsistencies between IdPs anyway.

    by cameronh90
  • It’s such a product of “Ooh! Markup languages! What can we use a markup language to solve!” When authentication is just not a document or data stream that needs marked-up.

    The article rightly connects this to XML, which was indeed the hammer to everything’s nail at the time

    I think we aren’t done with this problem yet, though. OIDC makes a lot of assumptions in service to Google and others. And tailscale as mentioned, despite “holding the line,” already reveals the cracks when things like GitHub accounts have to be treated differently from others.

    What we are missing is a provider-independent way to do this. I should be able to create an account and log in just about anywhere using a backend I control. It can be done, but not with what we have today

    by jmbwell
  • My favourite SAML horror story, is that it used to be, that by default the main c implementation of xmlsig would not just check the sig with the public key specified but would also:

    - check it against an hmac using a password specified in the attacker controlled document.

    - check the signature using web pki (so the attacker could sign the saml document with their TLS key for their own personal domain and it would always be considered valid)

    I honestly dont know how sites with saml arent getting hacked all the time. The only thing worse than the absolute terrible standards are the absolute terrible implementations.

    by bawolff
  • JWT uses a famously misdesigned signature scheme. It’s kind of amazing that this article uses JWT as an example of being better than SAML — SAML really is awful!
    by amluto

Explore Birbla archives