5 ms·

Out of curiosity (and ignorance), why SAML vs JWT or some less awful protocol?

jvoorhis 9y ago
There is a massive amount of enterprise software on the market which predates JWT, and enough inertia that vendors keep implementing SAML support for new products. It's not going away soon.
tptacek 9y ago
JWT is also an awful protocol, and it's also not an SSO standard. There's still time for us not to bet the farm on JWT, and I urge clients to avoid it.
- gridscomputing 9y ago
  Just Say No to JWT
- whatusername 9y ago
  Why not OIDC? (which is a SSO standard)
  - lvh 9y ago
    OpenID Connect is significantly less popular, especially among enterprise on-site apps, than SAML.
- ak217 9y ago
  Can you please elaborate on what's awful about JWT/OIDC? I ask because I've implemented SAML-based IdPs and SPs before, and SAML is a serious trainwreck of a protocol. Now I'm looking at implementing OIDC and at first glance it seems a lot more reasonable.
  - tptacek 9y ago
    They're basically the same protocol, but: * SAML has no alg=none. * JWT doesn't have "signature smuggling" problems. * SAML has schema validation. * SAML has more de-facto-required protective metadata (like audience restrictions). They are both truly terrible. Perhaps even a coinflip decision. But SAML is an actual real-world standard; it's how applications implement SSO. JWT is still floundering around trying to find a place to be essential. Let's hope it fails. Part of the point of implementing SAML was to implement a stripped-down version of it with none of the flexibility offered by libxmlsec1, which is the kernel for basically every SAML implementation.
    - ak217 9y ago
      Thanks. Can't say I agree on the basis of this list that JWT/OIDC is equally bad to SAML. SAML is an outdated, ill-designed piece of crap that is a ticking time bomb of an implementation nightmare, in large part because almost nobody truly understands the standard or the security implications of the underlying XML Security standards (having written https://github.com/XML-Security/signxml https://github.com/XML-Security/signxml for much the same reasons you cite, I can say it's a minefield). Reading the JWT and OIDC standards so far, they appear much more comprehensible and reasonable in their implementation options.
      - tptacek 9y ago
        I understand your logic, but the thing is: nobody implements dsig; they pretty all depend on a single dsig implementation (libxmlsec1). Writing a dsig implementation is obnoxious. That's not true of JWT; people definitely do implement their own JWT. They're both awful protocols, and for a lot of the same reasons.
      - lvh 9y ago
        Your comments about SAML are valid, but we're not implementing _all of SAML_. We're implementing the tiny subset that we can do safely once that you're actually going to use, once. This sidesteps some of the issues you're referring to. (Also: while I agree dsig is horrendous, I don't think that stops implementors: there's like 2-3 truly unique implementations, mostly libxmlsec1. People regularly write their own JWT but not dsig.) If you reduce the scope from every-document-with-the-letters-SAML-on-it to just-the-SAML-you-need, I think the coinflip becomes much more obvious. OIDC is pretty hairy too, for example: A) You may or may not get cryptographic binding. You can't tell from an intercepted interaction what security properties that interaction really has. For example: my understanding is that Google's OIDC implementation will bind to a specific client cred, so a leaked token sans leaked client cred isn't a big deal -- but that's something Google's implementation did, not something OIDC guarantees you, and it's not evident from the protcol flow. Do you have to validate that ID token signature? Turns out: no, because in practice everyone just does another leg and relies on TLS cert validation anyway, so this entire JWT dance was pointless. [0] This is one of my pet peeve regressions from OAuth1.0a to OAuth2. B) Quick: what's the difference between state and nonce? Which one do I use and why? Empirically (but somewhat anecdotally) implementers don't understand this. (I know _why_ it happened, I just don't think it should've.) ... and of course C) JWT bugs in homegrown impls: very real. You can sort-of reduce OIDC but you still end up with at least 3 distinct flows and then you might have a JWT'd ID token (so you may or may not have to do a third leg of extra work to actually get an identity assertion). OIDC is a meandering tree of options which does not fit in my head. TinySAML fits in my head. There's one obvious general flow and one tiny validation path. The only property you're not technically guaranteed is (cryptographic) audience restriction, but the IdP UX is in a unique position to de facto guarantee that (everyone gets their own key pair). When you add to that SAML's crushing market penetration, I think it is the right call. Finally, just to end with a slightly cheeky joke (please don't interpret this as the crux of my argument, I get that this is apples-to-oranges): > cat **.go | wc -l 17060 > curl -s "https://openid.net/specs/openid-connect-core-1_0.html" | pandoc -t markdown | wc -l 12897 Keep in mind that the OIDC Core spec says things like "validate per OAuth2 RFC", so the real spec is much larger, but there's also a lot of HTML markdown that pandoc doesn't compress well. [0]: https://developers.google.com/identity/protocols/OpenIDConnect#obtainuserinfo https://developers.google.com/identity/protocols/OpenIDConne...
- jf 9y ago
  By "JWT" do you mean the the format? (RFC 7519) Or perhaps you meant OpenID Connect? I can think of reasons for you to urge your clients to avoid JWT-the-format and certainly OIDC-the-standard. What do you suggest as the alternative?
  - lvh 9y ago
    (I work at Latacora and 'tptacek and I have worked on spitballing what that ideal protocol might look like.) Right now the answer is SAML because a) we can make it not a nightmare b) it is the de facto enterprise SSO protcool. To make SAML not a nightmare, we do the tiniest part of SAML that produces valid dsigs that other apps consume. It's not so bad as long as you just get that one basic case right and then NEVER TOUCH IT AGAIN. At some point, it's likely that we figure out what a good alternative would look like and publish that too, but it needs a clear value proposition that outweighs SAML's crushing market penetration. Something like "you can plausibly implement this in a dozen lines in every programming language" and "if you mess it up it stops working". You're probably right about the reasons OIDC isn't it. Maybe we just need a protocol with one more CSRF token parameter!
- eximius 9y ago
  Is there a non-awful protocol to bet on?
  - tptacek 9y ago
    No. Me and LVH keep spitballing what one would look like, but I'd want to have a userbase before suggesting anything concrete.
awalton 9y ago
The Enterprise SSO market is close to defacto standardizing around SAML AFAICT. Either your product supports it, or the very large enterprises with very large budgets can't use it, and your competitor that does support SAML gets the dollars instead.
- thiht 9y ago
  On a side note, is it necesary to use cryptic acronyms like "AFAICT"? If you don't want to write "as far a I can tell", why do you? It's kinda annoying to have to google for abbreviations like that all the time
  - koolba 9y ago
    It’s more annoying to have to type out the full expression each time you use it. That acronym has been in use on the internet for decades.
  - ape4 9y ago
    I thought it was a SSO protocol for a second. It sort of makes sense - Are you logged in? As Far As I Can Tell.
lvh 9y ago
I started talking about this elsewhere in the thread where someone suggests SAML's awful (agree) and OIDC is a better choice (disagree): https://news.ycombinator.com/item?id=15914881 https://news.ycombinator.com/item?id=15914881 I think it answers the question of why SAML nicely, but the TL;DR is: you can pare SAML down to a sane subset, and crushing market penetration.

There is a massive amount of enterprise software on the market which predates JWT, and enough inertia that vendors keep implementing SAML support for new products. It's not going away soon.

tptacek 9y ago

JWT is also an awful protocol, and it's also not an SSO standard. There's still time for us not to bet the farm on JWT, and I urge clients to avoid it.

gridscomputing 9y ago
Just Say No to JWT
whatusername 9y ago
Why not OIDC? (which is a SSO standard)
- lvh 9y ago
  OpenID Connect is significantly less popular, especially among enterprise on-site apps, than SAML.
ak217 9y ago
Can you please elaborate on what's awful about JWT/OIDC? I ask because I've implemented SAML-based IdPs and SPs before, and SAML is a serious trainwreck of a protocol. Now I'm looking at implementing OIDC and at first glance it seems a lot more reasonable.
- tptacek 9y ago
  They're basically the same protocol, but: * SAML has no alg=none. * JWT doesn't have "signature smuggling" problems. * SAML has schema validation. * SAML has more de-facto-required protective metadata (like audience restrictions). They are both truly terrible. Perhaps even a coinflip decision. But SAML is an actual real-world standard; it's how applications implement SSO. JWT is still floundering around trying to find a place to be essential. Let's hope it fails. Part of the point of implementing SAML was to implement a stripped-down version of it with none of the flexibility offered by libxmlsec1, which is the kernel for basically every SAML implementation.
  - ak217 9y ago
    Thanks. Can't say I agree on the basis of this list that JWT/OIDC is equally bad to SAML. SAML is an outdated, ill-designed piece of crap that is a ticking time bomb of an implementation nightmare, in large part because almost nobody truly understands the standard or the security implications of the underlying XML Security standards (having written https://github.com/XML-Security/signxml https://github.com/XML-Security/signxml for much the same reasons you cite, I can say it's a minefield). Reading the JWT and OIDC standards so far, they appear much more comprehensible and reasonable in their implementation options.
    - tptacek 9y ago
      I understand your logic, but the thing is: nobody implements dsig; they pretty all depend on a single dsig implementation (libxmlsec1). Writing a dsig implementation is obnoxious. That's not true of JWT; people definitely do implement their own JWT. They're both awful protocols, and for a lot of the same reasons.
    - lvh 9y ago
      Your comments about SAML are valid, but we're not implementing _all of SAML_. We're implementing the tiny subset that we can do safely once that you're actually going to use, once. This sidesteps some of the issues you're referring to. (Also: while I agree dsig is horrendous, I don't think that stops implementors: there's like 2-3 truly unique implementations, mostly libxmlsec1. People regularly write their own JWT but not dsig.) If you reduce the scope from every-document-with-the-letters-SAML-on-it to just-the-SAML-you-need, I think the coinflip becomes much more obvious. OIDC is pretty hairy too, for example: A) You may or may not get cryptographic binding. You can't tell from an intercepted interaction what security properties that interaction really has. For example: my understanding is that Google's OIDC implementation will bind to a specific client cred, so a leaked token sans leaked client cred isn't a big deal -- but that's something Google's implementation did, not something OIDC guarantees you, and it's not evident from the protcol flow. Do you have to validate that ID token signature? Turns out: no, because in practice everyone just does another leg and relies on TLS cert validation anyway, so this entire JWT dance was pointless. [0] This is one of my pet peeve regressions from OAuth1.0a to OAuth2. B) Quick: what's the difference between state and nonce? Which one do I use and why? Empirically (but somewhat anecdotally) implementers don't understand this. (I know _why_ it happened, I just don't think it should've.) ... and of course C) JWT bugs in homegrown impls: very real. You can sort-of reduce OIDC but you still end up with at least 3 distinct flows and then you might have a JWT'd ID token (so you may or may not have to do a third leg of extra work to actually get an identity assertion). OIDC is a meandering tree of options which does not fit in my head. TinySAML fits in my head. There's one obvious general flow and one tiny validation path. The only property you're not technically guaranteed is (cryptographic) audience restriction, but the IdP UX is in a unique position to de facto guarantee that (everyone gets their own key pair). When you add to that SAML's crushing market penetration, I think it is the right call. Finally, just to end with a slightly cheeky joke (please don't interpret this as the crux of my argument, I get that this is apples-to-oranges): > cat **.go | wc -l 17060 > curl -s "https://openid.net/specs/openid-connect-core-1_0.html" | pandoc -t markdown | wc -l 12897 Keep in mind that the OIDC Core spec says things like "validate per OAuth2 RFC", so the real spec is much larger, but there's also a lot of HTML markdown that pandoc doesn't compress well. [0]: https://developers.google.com/identity/protocols/OpenIDConnect#obtainuserinfo https://developers.google.com/identity/protocols/OpenIDConne...
jf 9y ago
By "JWT" do you mean the the format? (RFC 7519) Or perhaps you meant OpenID Connect? I can think of reasons for you to urge your clients to avoid JWT-the-format and certainly OIDC-the-standard. What do you suggest as the alternative?
- lvh 9y ago
  (I work at Latacora and 'tptacek and I have worked on spitballing what that ideal protocol might look like.) Right now the answer is SAML because a) we can make it not a nightmare b) it is the de facto enterprise SSO protcool. To make SAML not a nightmare, we do the tiniest part of SAML that produces valid dsigs that other apps consume. It's not so bad as long as you just get that one basic case right and then NEVER TOUCH IT AGAIN. At some point, it's likely that we figure out what a good alternative would look like and publish that too, but it needs a clear value proposition that outweighs SAML's crushing market penetration. Something like "you can plausibly implement this in a dozen lines in every programming language" and "if you mess it up it stops working". You're probably right about the reasons OIDC isn't it. Maybe we just need a protocol with one more CSRF token parameter!
eximius 9y ago
Is there a non-awful protocol to bet on?
- tptacek 9y ago
  No. Me and LVH keep spitballing what one would look like, but I'd want to have a userbase before suggesting anything concrete.

awalton 9y ago

The Enterprise SSO market is close to defacto standardizing around SAML AFAICT. Either your product supports it, or the very large enterprises with very large budgets can't use it, and your competitor that does support SAML gets the dollars instead.

thiht 9y ago
On a side note, is it necesary to use cryptic acronyms like "AFAICT"? If you don't want to write "as far a I can tell", why do you? It's kinda annoying to have to google for abbreviations like that all the time
- koolba 9y ago
  It’s more annoying to have to type out the full expression each time you use it. That acronym has been in use on the internet for decades.
- ape4 9y ago
  I thought it was a SSO protocol for a second. It sort of makes sense - Are you logged in? As Far As I Can Tell.

lvh 9y ago

I started talking about this elsewhere in the thread where someone suggests SAML's awful (agree) and OIDC is a better choice (disagree): https://news.ycombinator.com/item?id=15914881 https://news.ycombinator.com/item?id=15914881 I think it answers the question of why SAML nicely, but the TL;DR is: you can pare SAML down to a sane subset, and crushing market penetration.