Authentication vs. Authorization – What is the Difference?

What is the Difference Between Authentication and Authorization?

When talking with developers, or pretty much any non-security person, I find that people typically confuse the terms “Authentication” and “Authorization”. Most of the time, non-security persons equate the two terms and don’t realize what the difference is between them. So let me do my part to bridge this communication gap and try to clarify what these terms mean and how they are different.

What is Authentication?

First, let’s address “Authentication”. Authentication is the process of asserting what your identity is and then proving your identity. Clear as mud? Let’s try this another way. Suppose you are in your house and you have a knock at your door. You go to the door and ask “Who is it?” and the person responds with the name of your old college friend. But the voice didn’t sound right, so you look through the peephole to make sure it really is your college friend. It is, sounds like they have a cold, you let them in.

So what happened there? When they knocked and you asked who it was, they had to provide an identity. They could have said “mailman”, “Fred”, “Linda” or any other name, but they gave the name of an old college friend of yours. When they did that, they were asserting their identity. They were saying “I’m so-and-so, your old college friend.” In this case, not only were they asserting their identity, but they were providing proof as well, the sound of their voice. If you had recognized the voice and knew it matched your old college friend, you would have opened the door immediately. But the voice didn’t match because they had a cold, they failed to prove their identity with their voice. So you sought other proof, looking through the peephole to see what they looked like. When you saw your friend, that was proof that it was really them and you let them in. That’s authentication, asserting identity and proving it.

In applications, when we have to authenticate, we typically assert our identity with a userid or username. We then prove it by supplying a password which is supposedly only known by us.

The 4 Factors of Authentication

There are typically four ways an application or system can authenticate a user. The four factors are: something a user knows, something the user is (or uniquely has with regards to biometrics), something the user has or owns (such as hardware tokens), and the location of a user during the authentication attempt.   

Something You Know

The first of four authentication mechanisms- something a user knows stipulates a unique piece of information that only one exact user should know. This typically entails knowledge of a password, passcode, or answer to a secret question. It may also entail specific, previous account activity that only a specific user would know about (e.g. bank transactions, emails, etc.).

Something You Are

Something You Are” includes biometric data that is unique to a single individual, including iris scans, palm prints, fingerprints, etc. It is important to note that while passwords/passcodes can be changed, one’s biometrics cannot be changed at any time due to the relatively static nature of one’s anatomy.

Something You Have

Something You Have” includes ownership of a hardware token or device, which often has a key tied to certain systems or applications. When applied to a single individual, such a token can be used as a form of positive identification.  

Somewhere You Are

This is not usually a stand-alone factor, but is more of a contributing factor. Stand-alone factors are typically considered to be “something you know”, “something you are”, and “something you have”. One would usually not authenticate a person based solely upon where they are. One may use something you know in conjunction with somewhere you are to have stronger authentication. But it would not normally be considered two-factor authentication as two-factor typically requires two of the three stand-alone factors, i.e. something you know, something you have, and/or something you are.

That said, when authenticating with a system, the geographic location of the user (based on IP address) is often used to determine whether the login attempt (based on past login attempt locations) is authentic or fraudulent. For example, Google will indicate a security warning (or require dual authentication) if a user tries to log into the Google system from a location different than the normal location (all based on one’s IP address).

What is Authorization?

Ok, so hopefully we’re clear on what authentication, so what is this “authorization” term then?Authorization is the process of allowing access. It is predicated upon your proven identity; authorization depends upon authentication. If you don’t authenticate, you cannot really authorize (unless your authorization is simply to allow access to everyone). 

So let’s put this in terms of our old college friend again. Slightly different scenario, they WERE an old friend, but you had a falling out over a supposedly unpaid utility bill (which we all know you paid but they were too drunk that one night and thought it was pizza money). They’ve been harrassing you and now you have a restraining order on them. So when they knocked at your door and proved themselves to be your former old friend, do you authorize them to come into your home? Heck no, they’re not even authorized to be within 100 yards of your house! While they have been authenticated (you know who they are), they are not authorized to come into your home.

In a banking application, you authenticate yourself by providing your username and password. Based upon asserting your identification and proving it, the banking application allows you in, you log in. Now that you are authenticated, can you see your neighbors banking information (they bank at the same place)? No, while you are authenticated, you are only authorized to see your own data, not to see your neighbors data. That’s authorization.

Horizontal Authorization vs Vertical Authorization

There are two types of authorization, both of which are related to access control, and occur after the user is authenticated.

  • Horizontal authorization: dictates what access to data a user has. I can see my banking data but not my neighbors. My banker can see both of our data. That’s horizontal authorization.
  • Vertical authorization: dictates what a user can do. While I’m allowed to view my banking data, transfer money, etc, I cannot create a new business account. I need to go to my banker, provide all sorts of information and they open an account. I, as a general user, am not authorized to open a business account. My banker has a privileged access, more authorization and is allowed to open a business account in my name. That’s vertical authorization.

Authorization by Role Structure

A somewhat older system, authorization by role structure is a protocol where authorization is determined based on roles in an organization. With this system, profiles are made and set with default privileges (based on roles), giving the intended user a strict set of restrictions and limitations in a system. This type of system, however, is convenient in that it requires less upfront coding to be implemented. This type of system is also known as Role-Based Access Control (RBAC), and contrasts Permission-based Authorization protocols.  For my banking scenario, my neighbor and I are in the role of “General End User” whereas my banker may be in the role “Bank Clerk”.  

Authorization by Permission Based Structure

While RBAC is a strict system based on the user’s role, the permission-based authorization system allows more fine-tuned control over access to data and permissible actions. With the RBAC system, users are given roles with different limitations (privileges/permissions), while with permission based protocols, users are directly given a myriad of specific permissions to access certain data and/or carry out certain actions. Though allowing for more granular control over user permissions, this system requires more time for planning, coding and implementation.

Wow, that sounds difficult, why would we want this more granular (but more difficult to implement) authorization model? Let’s consider our banker. Her bank branch manager is going out of town so needs someone to open the safe on Monday. The normal “Bank Clerk” role does not have authorization to do this, you must be a “Branch Manager” to open the safe. The branch manager can grant the role of “Branch Manager” to the clerk so the clerk can open the safe when the branch manager is out. But when that happens, that bank clerk also can see all of the other bank clerks salaries, discipline history, and whatever other access the branch manager has. If they had a fine grained permission based authorization model, the branch manager could grant the clerk the permission to open the safe, and perhaps even specify that they can only do it on one specific day. Isn’t that better?


So a quick summary: The most critical difference between authentication and authorization is when you authenticate, you are showing the system who you are. Authorization, on the other hand, deals exclusively with what you (the authenticated user) are allowed to do within the application, what data you can access, and what access/permissions you are given within the application. There are different ways you can authenticate and there are different ways you can perform your authorization, but authentication is definitely very different from authorization. And hopefully that is crystal clear now.

About The Author

Cypress Data Defense

No Comments

Leave a Reply