Recently, I have been witnessing numerous discussions around Authentication (the process of verifying a user’s identity, e.g. checking in at a hotel, also referred to as AuthN) and Authorization (granting access to resources based on the authenticated user’s permissions, e.g. receiving your hotel keycard, also referred to as AuthZ). The conversations would often revolve around whether a specific process or action falls under AuthZ or AuthN, and where the boundaries between the two concepts lie. As a result, I found it challenging to follow these conversations due to the closely related and similar-sounding terms. In this post, I want to explain how the memory phenomenon “interference” contributes to the confusion between Authentication and Authorization, and share strategies to differentiate the two concepts more easily.
Why we mix it up: “Interference”
Interference is a memory phenomenon in which the retrieval of certain memories is inhibited by the presence of other, similar memories.
This interference can disrupt the learning process, making it difficult to recall specific information due to the presence of competing memories. In the case of Authorization and Authentication, the interference happens on multiple layers. One layer is the words themselves. They are almost the same. Especially since the abbreviations only differ by one character. This may sound trivial but I am sure this is a big reason why we mix them up and I think we should take this and the implications seriously.
Quick anecdote: Recently, I implemented a functionality in a shell script that allowed me to provide optional parameters for excluding or including files. For the first parameter, I decided to use “--exclude myPattern“. Ok, done. Second parameter: I realized that I didn’t actually want to include files; instead, I wanted the script to accept an argument with a string and then exclusively run the matched files. So my first thought was: “--exclusive myPattern“. With the idea of interference in mind, it becomes clear that names of parameters should never be assessed in isolation. Imagine the script now:
myscript.sh [--exclude myPattern] [--exclusive myPattern]I decided to change the “--exclusive” parameter to “--only” to prevent potential interference issues and maintain a clear distinction between the two parameters. This separation is particularly crucial because confusing the parameters could result in the exact opposite of the intended behavior.
Closely related and often overlapping ideas or terms make it challenging for us to distinguish between the two. It’s really not that we are too incapable to remember. Knowing about memory interference can make it easier for us to understand why some learning contents are just so difficult to retain. And as you hopefully saw in the small anecdote, it can help us write more easily understandable code, too.
How we can solve mixing AuthZ / AuthN: Focusing on API Access and User Identification
In his course “The Nuts and Bolts of OAuth 2.0“, Aaron Parecki cleverly avoids this interference by focusing on two distinct aspects of AuthZ and AuthN: API access and User Identification. By using these terms in our conversations, we effectively separate the two concepts and make it easier for everyone to understand and remember each one. This is also a wonderful way to decrease gatekeeping issues, as our communication will now be more inclusive to non-experts for a greater benefit of our discussions.
A practical example of the issues of interference in the Auth-case: OAuth is primarily a framework for granting API access (AuthZ), whereas OpenID Connect (OIDC) is an extension of OAuth for user identification purposes (AuthN). Many people might confuse OIDC with AuthZ due to interference, automatically assuming conceptual closeness and hierarchical equality due to the perceived similarity.
Conclusion
Being aware of memory interference can help us create better products by keeping it in mind when naming variables, parameters, and functions. Understanding interference and its effects on our learning process can also shed light on why we might struggle to differentiate between closely related terms, such as AuthN and AuthZ. I hope this knowledge can take some of the burden off your shoulders, as it did for me. 🌞
Leave a Reply