Authorization and authentication are often considered interchangeable. However, these systems do doing vastly different things. Understanding the differences between them is incredibly crucial for adequate security implementation.

Authentication = Who are you?

Authentication is essentially the practice of proving that you are who you say you are. Trust is hard to come by in any system. Trust is especially questionable when an external-facing system like an API has to negotiate trust with actors who may be coming from a variety of unique sources, each interacting with internal resources in different ways. Accordingly, authentication is one method by which a certain amount of trust can be assumed.

In an authentication scheme, the user promises they are who they say they are by delivering evidence to back up the claim. A standard method for authentication is the validation of credentials, such as a  username and password. In this authentication method, the user says they are who they say they are, and their evidence to back up this assertion is that they know a secret that only the user and the system itself knows.

Of course, the flaw in this logic is that someone other than the user can know this secret. Because of this, systems often implement a secondary (or tertiary) system for authentication verification. We call these approaches “factors” and split them between Single-Factor, Two-Factor, and Multi-Factor methodologies.

Factor methodologies are based upon a combination of variables around a secure string or key. These variables come in three categories:

• Physical: something the user has
• Biometric: something the user is
• Secret: something the user knows

In our Single-Factor example, the username is the identifier, and the securing method is a Single-Factor. The password is “something the user knows.” A key point here is that even if we ask for something else the user knows, we are still only asking for a Single-Factor. It is just as possible someone else knows a user’s password, as they may know the pin to access the account.

If we additionally ask for something from another category, we create a Two-Factor solution. Two-Factor solutions require two different types of credential authentication. For example, when a user supplies a username and password, a Two-Factor solution might also check against the MAC address of the system they are using to request access. If the MAC address, which is within the “something the user is” category, matches our internal known MAC address allocation for that user, then the request may be approved.

An authentication implementation needs one element from two or more categories to be considered Multi-Factor. So, technically speaking, Two-Factor is a Multi-Factor solution. However, when you have something from all three types, you enter a Multi-Factor class that is not synonymous with Two-Factor. For example, say our authentication scheme also requires a USB security key, or “something the user has.” If that same system required a password and fingerprint identification, it would become a Multi-Factor authentication process beyond Two-Factor.

Authorization = Can you do that?

Authorization is about proving that you can do what you say you can do. Authorization at times can involve authentication in that a system may first verify who you say you are before you can prove you can access what you claim you can access. This does not make the two terms synonymous, however.

People often conflate authorization with authentication since user experiences typically involve both simultaneously. To the end-user, the process as a whole seems to be a singular entity. The reality is that these things are very different, and their methodologies are thus not interchangeable.

Authorization is all about limiting access to resources depending on who is requesting that resource. Authorization solutions often use categories that restrict access to resources broadly by type of user. As an example, we may have an eCommerce server that has Users, Customers, and Vendors.

Users browsing the storefront do not need to touch much of the internal service. Accordingly, the User class is heavily limited. Customers, however, need to access Account Settings, Payment Details, Order Histories, etc., and because of this, the Customers account type will have much broader access rights. Vendors, on the other hand, need much more comprehensive access to an entirely different set of microservices and servers, and thus would have very different user rights. All of this is assuming that the user can be identified, of course.

User identification is often accomplished through the use of authentication, which grants a token to the user that can then be passed through to the Authorization server to grant defined rights. Due to this, users often think that you must have an Authentication system tied into an Authorization system. That’s not entirely true. Many Authorization servers utilize the user’s aspects, such as their network address, to verify that, regardless of who they are, they have the right to make the request. That said, the two are typically used in conjunction with one another.

The Core Difference Explained

While we’ve discussed these differences at length previously, it helps to consider the core differences through a real-world analog. Imagine you are going on a vacation, and have booked a flight.

When you’re at the airport, there are two things you must have regardless of where you’re going – your passport and boarding pass. When you go through security, you provide your passport. This passport identifies who you are, and it is considered a trusted document. The picture inside further shows that you are who you say you are by allowing security to see if you match your photo. Your passport is a form of authentication – you have attested that you are a particular person, and you have provided evidence that this is true.

When you get to your gate, however, a passport isn’t worth much. To actually board the plane, you need to present a boarding pass. This boarding pass was created as a token of trust between the airline and you – it conveys your ability to be on a flight. In that way, a boarding pass is a form of authorization, showing that you are allowed to do what you say you’re allowed to do.

OAuth Confusion

OAuth combines Authentication and Authorization to allow more sophisticated identity control and access management.

We should briefly mention that OAuth is the center of some confusion around authentication and authorization. OAuth is an authorization protocol (more specifically, a delegation protocol) – it is not a method for authentication.

The confusion arises when developers interact with OAuth in the wild. Because most OAuth implementations leverage a user identification model for granting authorization (that is, based upon the identity of the user, what is the scope of their permissions?), a user will often see this experience as seamless from identification to grant. That’s simply not the way things work internally, however. Once a user is identified, they are still outside of the OAuth system.

It’s only when a request is made for access, and the user requests a token from the authorization server that the OAuth internals are engaged. While the system may make use of identifiers for the user that were given during authentication, this occurred invisibly to the user previous to requesting anything from the OAuth systems. Put simply – OAuth is not an authentication protocol.

Real-World Example: eLearning

Let’s take a look at the difference between authentication and authorization in another hypothetical example. Imagine an application that engages in eLearning and delivers content to students across the world. This content takes the form of videos and quizzes. The app loads content from different microservices onto a web frontend.

When a user wants to access this system, the first thing they’re going to do is provide a username and password. This paired information is a form of authentication, but it’s not very secure. In theory, anyone could lose control over their password for a variety of reasons. Accordingly, every user must use a Multi-Factor system.

In this case, the school utilizes a Multi-Factor system consisting of both a username/password pair and a code generated from a mobile application. When logging in, after supplying the username and password, an app on the user’s phone pushes an authentication code that must be entered into a prompt on the learning application.

For other user groups, this method of authentication may not be enough, and a third multi-factor element may be needed. Teacher and Administrator requests must originate from a trusted, secure subnet of the local network. This is “something the user is,” and is a form of second-factor authentication.

Up until now, we have engaged entirely in authentication – proving that the requester is who they say they are. Now that we are reasonably sure they are who they claim, we need to make sure the user can do what they’re trying to do in the frontend.

This application has several levels of access that differ depending on who is requesting access to the resource. Teachers have Teacher credentials, students have Student credentials, and anyone working on the backend has an Administrator credential. What we have here is a series of levels, or “scopes.” These scopes define what rights each user group has and what they can do with those rights. These groups are defined and placed upon users by the authentication system internally, i.e., a user is flagged as Role:User , a teacher as Role:Teacher , etc.

A request for an authorization token is sent to an authorization server when a logged-in user goes through authorization. This server then responds with the token, which grants them certain rights. Based upon the request being made and the token the user holds, the server responds either with acceptance or denial. For instance, if a Student is carrying a StudentToken, they might be able to access coursework; if a Student attempts to access the GradesTable using a StudentToken, the system will recognize this is out of scope and will reject out of hand.

Using a system like OAuth, the scope of that token can be relatively granular and can expire with time. This is a good way to ensure access is not permanent and increase the security level on the application. The token itself is the form of authorization control, but because all of this happens invisibly to the end-user, it is often perceived that the token itself is also serving as an authentication tool. This is demonstrably false, and is not how these systems work. Systems like OAuth are for authorization, not authentication, regardless of how seamless the experience is.

Conclusion

Hopefully, we have made the line between authorization and authentication clearer. These topics, often considered interchangeable, are actually distinct, unique systems that do completely different things. Understanding these differences and understanding the caveats of each only makes the overall implementation that much better, clearer, and more effective. Was this a clear delineation? Is there anything else about this topic that needs clarification? Let us know in the comments below!

This document has been edited with the instant web content converting tool which can be found at htmleditor.tools – give it a try.