SAML Is Insecure by Design

Re:SAML Is Insecure by Design by jrockway on Thursday August 05, 2021 @06:24PM (#28080804)

I feel like we keep making this mistake again and again. Like JWTs can be signed with the "none" algorithm, which as you might guess is very easy to forge. Conformant implementations can see that and say "yup, that's a valid signature" and happily let any user grant themselves any access they want. Big mistake. It probably shouldn't be in the standard.

(I like PASETO instead of JWT, but nobody else in the world does, it seems, so we're stuck with the broken thing forever. Client libraries at least special-case "none" now and make it auto-fail, which has probably saved a few people that didn't actually read the spec.)

[ Parent | on HN ]

Re:SAML Is Insecure by Design by mwcampbell on Thursday August 05, 2021 @07:40PM (#28081483)

Thanks for mentioning PASETO. It looks good, except that it doesn't have a standard way of specifying expiration like JWT. But at least it's easy and safe to roll your own implementation of that part. Edit: My mistake; it's just the Elixir implementation of PASETO that doesn't support expiration.

[ Parent | on HN ]

Re:SAML Is Insecure by Design by tptacek on Thursday August 05, 2021 @10:24PM (#28082602)

PASETO is a bit of an odd duck, and isn't really an answer to the OIDC vs. SAML question. OIDC relies on JWT in the same way that SAML relies on DSIG, but there's a whole authentication protocol build around it. You would probably not be better off replacing an OIDC implementation with a hand-rolled authentication protocol based on PASETO.

The big problem here is that none of this matters. People do abuse OIDC as a general-purpose token for individual applications, but almost nobody does that with SAML. The point of these schemes is to federate authentication. In other words: it only matters what Okta and Google will agree to do. Your options are OIDC or SAML.

If you had to pick between the two, I guess you should pick OIDC, and think about what Ryan Sleevi said downthread about certificate verification; you'll want some kind of pinning scheme (pinning is a mess in client-server situations, but still sane in server-server applications; in fact, server-server pinning long predates browser public key pinning).

If you're not federating authentication, I don't think you should use JSON tokens of any sort.

[ Parent | on HN ]