Photo by Markus Spiske on Unsplash
What’s the difference between authentication and authorization? Does it matter which you use — or do you need both? Are they the secure app’s chicken and egg problem? Let’s dive in.
What is authentication vs. authorization?
Generally, programmers have subconscious reasoning for applying security and access controls to their applications. If questioned, they’ll describe a simple set of AUTH codes that protect the app. Are you using authentication, authorization, or both? What’s the difference? Do these get mixed up because they both begin with “AUTH” and are sometimes referred to in the same way as short-hand? Maybe some of this mix comes from each seeming to allow you to address the other’s concerns if you stretch it a bit.
But authentication and authorization are two separate things. Even if they go hand-in-hand for many applications, it’s essential to know the difference. Once you fully grasp this, it’s clearer how to implement each securely and effectively.
Authentication vs. authorization example
I will use the application and actor of the terms to discuss authentication and authorization. My background is in web applications, so I think of people using my web application as visitors. But actor refers to any human or computer accessing your application in any manner. The term application means any piece of software. So we could be referring to a website visitor, a desktop application user, or a consumer querying your API.
Authentication refers to identifying the actor using your application. That’s it. All authentication is responsible for is saying, “I can identify this actor” or “this actor is unidentified.” The meaning and description of authentication are simple — that doesn’t mean the implementation is. For example, you might have a username and password, tokens, cookies, JWTs, or other ways to authenticate a user. But, after the process is complete, we either can identify the actor or we can’t.
Authorization refers to the permission to accomplish a task in your application. Tasks can be simple, like listing resources or seeing the details of an object. Advanced ones may create, update, or move data through a complex business workflow. Now, this is important: authorization does not require an authenticated actor. It just so happens that most authorization decisions are based on the specific permissions of an identified actor, but that isn’t a requirement. We’ll touch on this more later. But authorization is the mechanism that answers the question: “does this actor have permission to do this action.” Both authentication and authorization are necessary.
Let me share a real-world example.
A client had requested that their web application list the resources for any visitor. Multiple pages had this listing shown and an API. They then asked that if visitors click through to the detail page or request details over the API, the visitor must be authenticated.
Now, check for authenticated users at the top of the code that retrieves details. The other code needs no checks because it doesn’t matter if they’re logged in. (That is to say, whether the user is authenticated or not, either situation allows access.) This application has only two states: the user is authenticated or not.
Only two states are rarely the case. Furthermore, there’s hardly ever a time that an application matures without expanding its access controls beyond these two states. So, with this knowledge in place, I decided to implement authorization on all endpoints.
They implemented an authorization layer that simply returned valid on the endpoints that displayed lists of resources (including the API). A simple class reused on each endpoint always authorized access to the list of resources. Then, on the endpoint with the details, I created another class that returned true only when I had the visitor’s identity.
Then it happened: business requirements changed! About a week after the web page was launched, the business decided they wanted the lists of resources to be locked behind authentication. Guess what? Because I had used authentication correctly, to begin with, it was super simple. Next, I modified the authorization class to list resources to check for an identified visitor. Done! I imagine a scenario where lists require an authenticated user, but details need a user who has a subscription. If that happens, I’m ready! I’m prepared for future changes in the business, too.
What is the point?
Authentication determines an identity of an actor. Authorization decides if an actor has permission to take action. Your application, no matter how simple, should use both hand-in-hand. Authenticate actors when you must. Authorize actors, regardless of their identity, for every action.
