Authentication vs. Authorization
Authentication and authorization are often interwined, but refer to completely different things. This post breaks down the difference and explores difference schemes for each.
If you recently heard your engineering team talking about “auth” – like something related to broken integrations or missing permissions – you might be confused.
That’s because every app needs to deal with two pieces of identity management, authentication and authorization, and they both start with “auth” – but carry very different meanings.
.png)
Authentication and authorization, critical components in application security, are frequently confused. In this article, we’ll define both authentication and authorization and explain how they work together to keep app data out of the hands of people who shouldn’t have it.
TL;DR: Authentication verifies identity. Authorization verifies privileges.
Authentication is identity verification
Authentication is the process of making sure the person trying to access your app is who they say they are. Really, this is the first step of app security. It’s like traveling to another country. Your passport is proof of who you are.
The first thing that comes to mind is passwords. Everybody hates passwords. No user likes remembering and typing out a complicated series of characters and few security professionals think passwords are effective. Troy Hunt, the man behind the infamously named website Have I Been Pwned?, found that in one breach, 86% of users had passwords already revealed in previous data breaches. We’re talking stuff like 123456, qwerty, and password (shudder).
Security is a spectrum. With passwords at the bottom, other form of authentication, such as biometrics and multifactor authentication (MFA), range from less secure to more secure. When forming your authentication strategy, keep in mind the sensitivity of your data and how easily bad actors might fool your system.
Four methods for authentication
Throughout the history of digital authentication, different strategies for verifying someone’s identity with technology have been tried. Below are the most common modern methods of authentication to consider when forming your own authentication strategy.
One-time password (OTP)
Believe it or not, an OTP is exactly what it sounds like: a passcode that is used only once. There are two methods for generating OTPs:
- Time-generated OTPs — a new passcode is based on the current timestamp.
- Math-based OTPs — a new passcode is generated based on the previous passcode using a one-way function.
OTPs are commonly delivered to the user via authenticator apps or by sending the code to the user’s phone or email. Some systems using OTP may even have a physical fob with the code.
Single sign-on (SSO)
When one application manages the logins for all other applications, it’s called SSO. Hence the name “single” sign-on. You only need to sign in to one app to access all the others.
With so many usernames and passwords to remember, millions of app users have benefitted from SSO. Their data is safer because of it. Using the same password for all accounts is bad practice, and creating passwords that are easy to remember (or to guess) is weak.
With SSO, you can continue forgetting random strings of numbers and letters and instead let an app do the heavy lifting.
Biometrics
Ever used your fingerprint to open your phone? What about your face? What about your blood? Wait, what? That’s not a thing yet. But still, these are all examples of biometric authentication. It’s the practice of taking something that is biologically you, like your fingerprint, face shape, or even DNA, as proof of who you are.
This area of authentication technology is rapidly changing. Scientists are currently studying ways that behavior (like gait) can be used as identity verification as well.
Multifactor authentication (MFA)
MFA combines multiple authentication types so that you can be super-duper extra sure that someone is who they say they are.
All methods of authentication offer the most security when working as a group. After all, a username and password combo is only as safe as your ability not to write it on a Post-it note and stick it on your computer.
A typical example of MFA would be using a username and password to log in to an app, and then having an OTP sent to your phone via SMS. You’re given a small time span to enter the OTP before it times out, and you must get another code or be locked out of your account.
Multifactor authentication is quite secure because it requires something you know (password) and something you have (a smartphone on which to receive an OTP).
By the way, if the history of authentication intrigues you, you can read more about the wicked genius of the old-school computer scientists who developed the technology, read more here.
Authorization is privilege verification
Authorization is the process of granting authenticated users varying levels of access depending on what type of credentials their work requires.
Let’s pretend that we have an e-commerce store that sells socks. Our amazing company employs engineers, customer support specialists, and marketing coordinators. All of the people in these different roles will need to access different kinds of data about the app.
The engineer will need to be authorized to view audit logs of what happens in the app so they can debug problems that crop up. Maybe the online store crashes when a customer (let’s call him Willie) with particularly chilly toes and a disdain for doing laundry attempts to order 365 pairs of fuzzy toe socks.
The engineer’s authorization should allow them to see the customer’s click path and determine what went wrong.
The customer support specialist will need authorization to view and edit the customer’s personal data in order to assist the customer with their transactions. Maybe Willie was silly and accidentally sent his shipment of 365 fuzzy toe socks to Philly, when he meant to send it to Pittsburgh. No worries.
Our customer support specialist has access to Willie’s recent order and can easily change the shipping address before the socks are sent out.
Last but not least, the marketing coordinator just needs access to information such as order frequency and location. The marketing coordinator is tasked with gathering and analyzing data about how certain toe socks are performing in our store. They can deliver powerful insights, such as “Fuzzy socks are up by 500% in Pennsylvania” just by accessing some order data.
They don’t need personally identifiable information (PII), like Willie’s full name or address.
When forming your authorization strategy, keep in mind what types of data your app uses and what levels of access each employee should have. In some cases, your data may be a free-for-all, and authorization is open to everyone.
Other times, particularly if you deal with any protected data (like that covered by HIPAA), you’ll need to be careful with your privileges.
Four models for authorization
Over time, four main models for access control have cropped up:
- Discretionary Access Control (DAC)
- Mandatory Access Control (MAC)
- Role-based Access Control (RBAC)
- Attribute-based Access Control (ABAC)
We’ll cover the basics of these four so you can keep them in mind when building your authorization strategy.
Discretionary Access Control (DAC)
At a high level, DAC determines privileges for each user, depending on who they are and what access groups they are in. Each object is allowed to be accessed by certain groups or identities.
One of the big footnotes to DAC is that whoever is in charge of access controls (like a system administrator) is able to pass equal permissions to other users.
Mandatory Access Control (MAC)
MAC is at a lower level than DAC. Basically, the operating system (OS) determines the authorization of a subject to access an object. MAC tends to refer to subjects, such as threads and processes, and objects, such as files and memory. The OS has operation rules (sometimes known as a policy) for every object and subject and uses those rules to determine access rights.
Generally, MAC could be used to overwrite discretionary access controls on the user level.
Role-based Access Control (RBAC)
RBAC is different from DAC and MAC, in that it can be used to enforce those access controls. It works by using previously defined roles that are made up of various privileges.
Each subject in the system is assigned a role. Usually, the system is configured so that these roles make sense on a business level.
For instance, a user who needs to update the username of a customer in a database file would have a role like “customer support agent,” and “change username” would be a privilege that that role is allowed.
Attribute-based Access Control (ABAC)
ABAC is considered policy-based rather than role-based like RBAC, which means that there is an overarching authorization model that allows privileges to users based on a collection of attributes. Attributes can be defined in regard to the user, resources, objects, or environment.
Essentially, authorization is allowed if the combination of all attributes returns a boolean “true.” Anything that could flip that to false is not authorized.
Securing your app with authorization and authentication
Now that you have a clear understanding of what authentication and authorization are, you still won’t be able to make your client happy by adding “auth” to the product by EOD because you failed to verify whether they wanted the “-entication” or the “-orization” kind of “auth.” Oh well.
In reality, your auth strategy should be built in a way that best serves you and your client’s needs for data security. In some instances, you may not need any kind of authentication or authorization. This could be something like a website, where you just host the same GIF playing over and over again because it makes you feel slightly less existential dread during the day.
In some scenarios, you could just want to handle authentication but not worry about authorization. This might be some kind of app you want to use to track data about who is accessing it, but you don’t to give them any different kind of abilities based on who they are.
In a final, much more common scenario, you will want to use both authentication and authorization together. After all, you cannot grant role access to users without knowing who they are. That would be anarchy! Generally, this works well as an auth strategy because it first verifies the identities of your users and then grants permission to just some of your objects based on who the user is.
Hmmmm, maybe your client wanted you to add both authentication and authorization to the app. Good thing you understand both and now know how!