The oft-linked Eran Hammer blog post isn't too relevant here, even if its critiques of OAuth2 are valid from the perspective of OAuth1. Really, they're fundamen

The oft-linked Eran Hammer blog post isn't too relevant here, even if its critiques of OAuth2 are valid from the perspective of OAuth1. Really, they're fundamentally different protocols with different goals, and after all that drift in the working group, not changing the name and pretending it's an increment of version was bad form. Nonetheless, OAuth2 just defines the roles of the players in a situation where an application wants to act on behalf of the user, and defines a few useful interactions between them. OIDC then layers on top of OAuth2, by defining custom payloads that communicate authentication requests and responses. It does so by relying heavily on the JOSE specs. The end result of all this layering is a protocol that's conceptually similar to SAML, despite looking and feeling rather different. Meanwhile, all the truly hard stuff, like Discovery and Federation, are additional specs alongside. They see much less use. There's sometimes bad implementations, and there's sometimes authorization flows that aren't actually OAuth2 but merely "OAuth2-inspired". In these, and in transmitted payloads, gratuitous differences from vendor to vendor are irksome. The same stuff happens in SAML-land too. There are products big and small, IdPs and SPs, that don't actually comply with the protocol. Sometimes the product is fine in theory, but it's misused or misconfigured. Sometimes the IdP product is big enough that they have little incentive to improve, and sometimes the SP is desirable enough that you're being pressured by your employer to integrate with them regardless of any protocol shenanigans.