Recently, Okta released an article titled “Nobody Cares About OAuth or OpenID Connect” that authoritatively stated that “Developers don’t care about OAuth or OpenID Connect”. I strongly disagree.
I recommend you give the article a read before reading my rebuttal below (although you might want to skip to “Why Nobody Cares About OAuth and OpenID Connect” and onwards).
Their key takeaways are:
- The security community needs to keep developers safe
- Developers using OAuth and OpenID Connect client libraries is similar to them rolling their own crypto
- Client libraries should handle all of the authentication and authorization for developers, not just OAuth and OpenID Connect
My Background
I am a developer who teaches other developers about OAuth and OpenID Connect. The company I work for does okay for itself, we do not lack for customers. Customers I have worked with include startups, SMEs, household name brands, and large financial institutions with over 20 million users.
What I’m driving at here is that my role at Rock Solid Knowledge proves that there is an appetite from developers to learn more about OAuth and OpenID Connect and how to use them effectively. So maybe it’s a little too much to state that developers don’t care.
My Experience with Developers
A lot of my time is spent training developers that they aren’t using Okta, or IdentityServer4, Azure AD, or Auth0; but rather that they are using OAuth and OpenID Connect. Once they understand that, they are no longer constrained to proprietary client libraries, they can now effectively Google all of their problems, and their ability to secure their apps is dramatically increased.
Without this knowledge I have seen developers:
- Use the implicit flow, and a localhost redirect URI in a mobile application (Okta, please update your article)
- Write hash fragments with access tokens to the Location header
- Use the ROPC grant type everywhere
- Store refresh tokens in a SPAs local storage
While this lends to the article’s thinking that OAuth and OpenID Connect is hard and developers don’t need to know about it, I would argue that further abstracting this behind a generic authentication/authorization library would only make things harder for developers, further entrenching them in the mindset of “I am using Okta”, as opposed to “I am using OAuth to authorize access to my API”.
Even with a generic authentication/authorization library, some of those issues above may still be present. Where is the line drawn?
A comparison is made with the standard advice: “Don’t roll your own crypto”. Sure, OAuth is something new (ish) to learn, but it is no way as complex as cryptography, and, much like cryptography, OAuth is not the result of a few super genius experts, but rather the broader developer and security community. It is a group effort and collection of agreed best practices. Should developers, the people using the technologies, be excluded from the OAuth community?
A better approach would be to offer more best practice documents. These are excellent developer resources, with a perfect example being “OAuth 2.0 for Native Apps”. This document is simple enough to read and tells a developer in no uncertain terms how to use OAuth securely for that application type, and even which technologies to use or avoid. Maybe this should be the focus of the security community, rather than thinking of developers as incapable.
My Experience with Client Integration
The article lands upon the conclusion that developers shouldn’t use OAuth and OpenID Connect client libraries, but instead use generic authentication and authorization libraries, that completely abstract away claims, tokens, and the protocols themselves.
Sure, that sounds great! Do you have something to use in my customer’s legacy ASP (classic) site? How about Webforms? How about the newest version of ASP.NET Core that came out yesterday? Will it support every obscure business requirement that must be customizable at runtime and be instantly revocable? Do you support this proprietary push notification that our security team insisted we use?
This is my teasing way of saying that there will always be scenarios where developers will need to create something for themselves and use OAuth and OpenID Connect directly. By first wasting time on a generic library, they are then on the back foot by having to start over again. Besides, OAuth and OpenID Connect are only a solution to a part of the identity problem. User level authorization is still something being debated. Surely, we should at least agree on that first?
We will never be able to anticipate all business requirements and emerging technologies, but I think this is something that OAuth and OpenID Connect have excelled at, despite complaints of the number of expansion specifications (which has a lot to do with how IETF operates).
And let's not forget the law of leaky abstractions: "All non-trivial abstractions, to some degree, are leaky."
The proposed abstraction is certainly not trivial, and will eventually expose the developer to the world of OAuth and OpenID Connect.
Again, we have put the developer at a disadvantage.
They had no idea they were using these protocols, and won't have the vaguest idea how to debug this pressing production issue.
To again quote Joel Spolsky, [...] abstractions save us time working, but they don’t save us time learning
.
To play devil’s advocate, even OAuth and OpenID Connect client libraries don’t always give us everything we need, nor do they necessarily move with the times fast enough. Just look at the fuss caused by the proposed best practices for browser-based applications, or the growing recommendation to use PKCE across the board. There are still times where a developer must build upon the client libraries (or better yet, contribute to them) to secure their application type.
Movements such as the OpenID Certification program are ensuring that all client libraries meet a certain level of quality and functionality. Focusing on programs like this and increasing awareness of them seems like a much better service for developers.
What developers don’t want to use is a proprietary, product-branded, black box. While these libraries are great for vendor lock-in, there is little more frustrating for a developer to use.
My Experience with the Identity Community
After attending my first few identity-centric conferences, it seemed to me that the majority of the identity community are IT Pros and security professionals (with most of those coming from an IT pro background).
We desperately need more developers who understand OAuth and OpenID Connect. Diversity is something we can always benefit from.
Conclusion
I believe hiding the complexities of OAuth and OpenID Connect to “keep developers safe” is doing them a disservice. Depending on your background, OAuth is nowhere near the same level of complexity as cryptography.
The identity community is making strides in ensuring the quality of client integration due to the use of best practice documents and certification programs. I think this is a much more realistic goal than what the article proposes.
Education is the key to solving OAuth security issues, and commercial identity providers need to be more transparent about the protocols that are in use. Articles should be about “Integrating Angular with OpenID Connect”, not “Integrating Angular with Okta”.
Developers love learning something new, and we really do care about the technologies we are using. It’s why we chose the career.