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.
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
[0]: https://developers.google.com/identity/protocols/OpenIDConne...
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.
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.
* 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.