Thanks for the thorough response. I haven't heard of TinySAML before, are we talking about 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://wiki.mozilla.org/Security/Guidelines/OpenID_Connect, and the Google docs you linked, but would like to learn more/find better libraries.
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.
The actual Go package is "trivialsaml". :)
Would be interested to see the source (for reference purposes only, anyway - I prefer Python myself) or any other resources you recommend.
It'll all be public in a few weeks.
I hope both SAML and OIDC go away.
And are replaced with what?
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...
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):
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/OpenIDConne...