Do developers need to understand the underlying details of OpenID Connect, OAuth, and other standards to implement authentication and authorization? Maybe yes, maybe no. Let’s explore some different points of view.
The Hard Journey to Identity
Sooner or later, a developer will have to deal with authentication and authorization, whether they are building a SPA, an API, a mobile app, or a microservice, whether they are using Java, C#, JavaScript, or other programming languages.
Some will probably try to implement a homemade solution because it is, after all, a simple login box 😱. And after overcoming the hurdle of username and password authentication, they face the burden of single sign-on, delegated authorization, Multi-Factor Authentication, and so on. Perhaps just by trying to build a homemade solution, they will understand the complexity of the problem and look for proven solutions.
As they learn about standards such as SAML, OIDC, OAuth, WebAuthn, etc., they will probably realize that they have tried to reinvent the wheel. And most likely, they have not considered scenarios that could compromise the security of their application.
But even if you look at these standards from a high level, you will realize that there are many facets, many different scenarios to consider, several details and nuances.
In summary, sooner or later, developers will learn that Identity management is hard.
To Know or to Ignore? That Is the Question
Once they understand that following standards is the high road to managing the identity of their application users, developers are at a crossroads:
- Understand and implement the details of these standards.
- Use a library or SDK and completely ignore the underlying complexity.
The two options seem divergent: know the details or ignore them altogether. Perhaps they reflect the two approaches that developers can take to deal with standards, not just in the Identity space. The choice may depend on the developer's inclination but also on other factors, such as competencies, available time and budget, and so on.
Developers don't care...
Someone has argued that "99.99% of developers out there don’t know (or want to know) anything about OAuth, OIDC, or any other security specifications. All they want to do is find the simplest and most straightforward way to support user authentication and authorization in their application. They don’t care about standards, specifications, grant types, JWTs, or scopes and timeouts – all they want to do is log a user in and check to see what permissions they have."
That's pretty understandable. As a developer, I want to solve my problem as quickly as possible without getting lost in the details. If I'm developing an e-commerce application, I want to focus on the business logic of my application. I don't want to worry about every technical detail that my application relies on. I don't want to know the little internal details of the framework my application runs on, the necessary compilation steps, or the network infrastructure that it will use. I prefer to use tools that take care of that and abstract the internal behavior. Tools that are accurately built by real experts in their field. After all, that is what we at Auth0 are trying to do: take care of the complexity of Identity and free developers from knowing the details of standards and security issues.
...developers do care
On the other hand, there are those who argue 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."
Well, in my experience, that is also true. I've found a lot of developers trying to understand how to properly use an access token and which OAuth flow to use in a given scenario, even if they're using a third-party library. And I think that's pretty understandable as well. While I don't want to learn every little detail of the infrastructure my application will run on, I can't ignore it completely. Some features of my application might depend on it to work well.
So, what is the right choice to make when dealing with standards in the Identity management space (and also in other areas)? Know their details or ignore them?
Interested in getting up-to-speed with JWTs as soon as possible?
Download the free ebook
The Third Way
“Zen and the Art of Motorcycle Maintenance” is one of the cult books of the 1970s. It is a kind of philosophical novel in which the author, Robert M. Pirsig, explores the concept of quality by interweaving it with his almost-fictional biography and his passion for motorcycles.
Two types of developers
In one of the book's disquisitions, the main character divides humanity into two types:
- Those who see the world as a complex mechanism to be explored in its inner workings (classical understanding).
- Those who see the world primarily in its superficial appearances (romantic understanding).
Romantic people are those who ride their motorcycles without worrying about how they work. They are not interested in the mechanics of the drivetrain or the ignition or the lubrication system. If their motorcycle breaks down, they take it to the mechanic. And they hardly hear in advance that something is going to break down.
Classical people are those who feel their motorcycle. When they ride it, they hear every little noise, they imagine the movement of the chain, they are one with their means of transportation. They feel when something is about to go wrong because they know every little part of their bike and prefer to fix it themselves.
These two categories of people also apply to developers, in my opinion. Romantic developers don't care about the underlying technology or standard. They want to use a library that simplifies their lives and gets right to the point. Classical developers, on the other hand, want to know what happens inside a library: what technology, standard, and algorithm it uses. Classical developers are the traditional hackers, the ones who get their hands dirty with grease to fix or customize the engine of their motorcycle.
Maybe the choice between the two options for dealing with Identity management is driven by these two developer personalities. And perhaps each of you can identify with one of these two profiles.
"Although motorcycle riding is romantic, motorcycle maintenance is purely classic."
— R. M. Pirsig
In medio stat virtus
Starting from a classical position, the protagonist realizes that virtue lies in the middle, just as the Latins used to say (in medio stat virtus). And virtue, excellence, quality is what he is looking for: what the ancient Greeks called areté and Eastern cultures call Dharma.
While each developer tends to use a romantic or classical approach to the Identity management problem, based on their personal nature, I think that each of the two positions should only be a starting point.
If Identity management is not your business, it is not cost-effective to implement standards from scratch and take care of all the details. Standards evolve, as do scenarios, best practices, etc. If your core business is not Identity management, implementing OIDC, OAuth, and the other standards may be too expensive and risky for your project.
On the other hand, simply using a library or SDK and ignoring what lies beneath it cannot last long. It can be frustrating when problems occur and you have no idea what is going on. You don't know if the problem depends on your code, your configuration, your library, the environment your application is running in. Understanding at least at a high level how the library you are using works and what standards it uses can help you at least to narrow down the area of investigation when problems occur.
In summary, I think every developer has their own starting point for dealing with problems. But whether you decide to do everything yourself based on standards or prefer to ignore everything under a library, in either case, it will impact the cost of your application.
I think the best solution is to get a medium level of expertise in technologies and standards so that you can at least choose your library with knowledge. What do we call this type of developer? The pragmatic developer?
What Auth0 Offers
Whether you are a romantic or classical developer, Auth0 helps you integrate authentication and authorization into your applications by letting you use the approach you prefer.
You have SDKs and libraries that abstract the complexity of Identity management, but you are not locked into using our libraries. Your choice is free. But you can look into our code and contribute.
You also have documentation on standards, guides specific to your favorite framework, code samples, videos, and a community to share what you've learned.
You can choose your preferred path to becoming a pragmatic developer by taking advantage of the resources Auth0 provides.
What kind of developer are you? Are you romantic or classical? Are you aiming to become a pragmatic developer? How can we help you? Leave your comments below.
