You frequently hear authentication and authorization listed together in one breath. Often, people conflate these terms and simply say “auth”. It’s no wonder that some of us confuse the two. If you care about security of your application and privacy of your users, it is important to know that there’s a difference between these two terms though. So what is the difference and why does it matter?
When speaking about authentication (also called AuthN), think about identity. Authentication tries to answer “is this person who they say they are?” It’s a software equivalent of a passport or national ID check. Or to put it in more realistic terms, authentication is a similar process to that moment when you look at another person’s face to recognize that this is your friend from college and not your annoying second floor neighbor.
On the other hand, authorization (also called AuthZ) is all about permissions. Authorization answers a question “what is this person allowed to do in this space?” You can think of it as your house key or office badge. Can you open your front door? Can your annoying neighbor enter your apartment at will? And more, once in your apartment, who can use the toilet? Who can eat from your secret stash of cookies tucked away in your kitchen cupboard?
While related, authentication and authorization are entirely different problems. It may be tempting to lump them together, but that usually results in one of them being neglected. Sadly, the part that tends to be neglected the most is the authorization. It’s easy to see why.
What does it mean in a software context?
In software, you can’t really perform authorization without prior authentication. Unless every user can do everything and everything is public, you have to be able to distinguish between the users. That’s why it starts with authentication. Authentication is a very visible process - you get a login form, or a button to use a federated identity provider (login with Google, Twitter, Office 365, etc.) And since authentication is the first step that’s very visible, it gets a lot of attention from developers. When you’re used to thinking about AuthN and AuthZ simply as “Auth”, after you have spent a considerable amount of time ensuring that users can log in securely, it’s tempting to think you’re mostly done with your “auth”.
In reality, that’s where the actual work starts. Once you know that the user is who they say they are, you need to consider what they are able to access and what operations they can perform. That’s authorization. Where authentication drops off (user is logged in), authorization picks up and continues as long as the user interacts with your software. There are a lot of intricacies involved in this process. How many different resources are there? Are they treated the same or different? Can users share resources? If so, who decides what’s shared and what isn’t? What happens to a shared resource when it gets deleted by the owner? The list goes on. If you don’t consider authorization as its own, separate class of problems, your users will encounter a lot of edge cases that may or may not result in a PR disaster for your company.
If you don’t tease authentication and authorization apart, you run into a risk of building a lot of inconveniences if not bugs into your software. Depending on what your software does, either AuthN or AuthZ may be more important. It makes sense to design your solution with full awareness which one is which.
Authorization in practice
Let’s illustrate this with an example. You’re in charge of security of an apartment complex. Your task is to ensure that people can access their apartments and no unwanted visitors can do the same.
If your first thought is authentication, you will likely post a guard at the entrance, asking everyone to show their ID in order to get in. Now that you have a guard, you will give the guard a list of all tenants, so that only the right people get in. Problem solved. Oh, but wait! You came back from work only to see your annoying neighbor is there on your couch, eating from your secret stash of cookies. The guard at the entrance obviously didn’t prevent her, she’s a tenant in the building after all. In software terms, this would be an equivalent of Zoombombing or private pictures leak. Not so unheard of.
If you approach the same problem as authorization-first, perhaps instead of posting a guard, you would give each of your tenants a set of keys instead. Everyone would get the same kind of key to open the main door, and additional key unique to each apartment. Now your annoying neighbor can only visit you when invited, and she surely won’t get the cookies! This is definitely a much better solution. Still, it’s not complete. What if you lose your keys? What if someone finds your lost keys and decides to make themselves at home in your apartment? You wouldn’t know, because in that scenario you’re not getting into the building ever again. In software, this would be the same as your ex hacking into your email account and changing the password. Not very fun.
The truth is, you need to think very carefully both about authorization (what can each user do) and authentication (is this user who they say they are). Despite them having similar names, they are two different classes of problems, each with their own unique edge cases to consider. If you lump them together, you end up with a problem one way or another.