4 ms·

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

by 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...
- tptacek 9y ago
  If that's my trivialidp repo, in fairness, there are 2-3 other private repos that are important deps. :)
- ak217 9y ago
  Thanks for the thorough response. I haven't heard of TinySAML before, are we talking about https://github.com/nicolas-raoul/Tiny-SAML-IDP https://github.com/nicolas-raoul/Tiny-SAML-IDP? In general, my experience with SAML in the wild is congruent to yours with OIDC: it's a meandering tree of crappy options that doesn't fit in my head. I'm discouraged to hear the same opinion about OIDC. Do you really think SAML has a bigger future than OIDC? Are there implementation notes or library implementations of SAML and OIDC that you would recommend as good references? I'm aware of Okta's docs, https://www.owasp.org/index.php/SAML_Security_Cheat_Sheet https://www.owasp.org/index.php/SAML_Security_Cheat_Sheet, https://wiki.mozilla.org/Security/Guidelines/OpenID_Connect https://wiki.mozilla.org/Security/Guidelines/OpenID_Connect, and the Google docs you linked, but would like to learn more/find better libraries.
  - tptacek 9y ago
    I hope both SAML and OIDC go away.
    - ak217 9y ago
      And are replaced with what?
      - lvh 9y ago
        We don’t think it’s been written yet. But punchline: don’t support every combination of encryption and signing; sign in 1 place and 1 place only, tiny set of protocol versions...
  - lvh 9y ago
    Sorry for the term confusion: TinySAML is what I’m informally calling the tiny subset of SAML we’re choosing to care about. Neither full-SAML nor full-OIDC fit in my head; I’ll also concede that full-SAML is much more complicated than full-OIDC, but that doesn’t matter: narrowing scope is much more effective for SAML than OIDC. I hope both protocols become obsolete. SAML may not be the future, but it’s definitely the present. I’m not convinced OIDC is materially better. ‘tptacek will have much more informed opinions about relative SAML library quality so I’ll leave that to him.

by ak217 9y ago

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...

tptacek 9y ago
If that's my trivialidp repo, in fairness, there are 2-3 other private repos that are important deps. :)
ak217 9y ago
Thanks for the thorough response. I haven't heard of TinySAML before, are we talking about https://github.com/nicolas-raoul/Tiny-SAML-IDP https://github.com/nicolas-raoul/Tiny-SAML-IDP? In general, my experience with SAML in the wild is congruent to yours with OIDC: it's a meandering tree of crappy options that doesn't fit in my head. I'm discouraged to hear the same opinion about OIDC. Do you really think SAML has a bigger future than OIDC? Are there implementation notes or library implementations of SAML and OIDC that you would recommend as good references? I'm aware of Okta's docs, https://www.owasp.org/index.php/SAML_Security_Cheat_Sheet https://www.owasp.org/index.php/SAML_Security_Cheat_Sheet, https://wiki.mozilla.org/Security/Guidelines/OpenID_Connect https://wiki.mozilla.org/Security/Guidelines/OpenID_Connect, and the Google docs you linked, but would like to learn more/find better libraries.
- tptacek 9y ago
  I hope both SAML and OIDC go away.
  - ak217 9y ago
    And are replaced with what?
    - lvh 9y ago
      We don’t think it’s been written yet. But punchline: don’t support every combination of encryption and signing; sign in 1 place and 1 place only, tiny set of protocol versions...
- lvh 9y ago
  Sorry for the term confusion: TinySAML is what I’m informally calling the tiny subset of SAML we’re choosing to care about. Neither full-SAML nor full-OIDC fit in my head; I’ll also concede that full-SAML is much more complicated than full-OIDC, but that doesn’t matter: narrowing scope is much more effective for SAML than OIDC. I hope both protocols become obsolete. SAML may not be the future, but it’s definitely the present. I’m not convinced OIDC is materially better. ‘tptacek will have much more informed opinions about relative SAML library quality so I’ll leave that to him.