OAuth 2.0 and OpenID Connect: Now What?
A former Toad recently asked my opinion about this article:
OAuth 2.0 and the Road to Hell
The question is well-timed: I'm in the middle of a big OpenID Connect / OAuth 2 implementation.
That article was written three years ago, but I think Eran Hammer is essentially correct: the standard (especially OpenID Connect) is big, complicated, and enterprise-y.
Overall, the loudest critique of OAuth 2 seems to be it's dependence on TLS. The argument is that 1.0 provided defense in depth with two layers of cryptography (TLS and signatures). I'm not convinced this is a big problem – we don't really expect this of other applications (SSH, and entire web itself, also rely on a single layer of transport encryption). And that's also misleading about the intent of 1.0 signatures, which were really designed to operate safely without TLS, so many implementations have only a single layer anyway.
Organizations that want a belt-and-suspenders approach to encryption can (and often do) use a VPN.
It's true that interoperability is an issue – unlike SAML (which is also enterprise-y, but has a handful of explicit protocol bindings), OAuth 2 is a framework, and much is left up to the implementor. For example, what do the bearer tokens mean? OAuth doesn't specify, so a server needing to verify a token must have out-of-band knowledge of the identity provider's implementation.
I think the OAuth brand is in decline. This framework will live for a while, and given the lack of alternatives, it will gain widespread adoption. But we are also likely to see major security failures in the next couple of years and the slow but steady devaluation of the brand. It will be another hated protocol you are stuck with. [emphasis in original]
Thee years later, I think it's safe to say this prediction has not come true.
Many large IDaaS providers have already adopted OpenID Connect (such as Microsoft Azure AD, Google, OneLogin, and SalesForce), and I expect it to become ubiquitous in the future.
Add new comment