Authentication vs. authorization

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.

Authentication (or AuthN) verifies who the user is, while authorization (or AuthZ) determines what resources a user can access. While both are essential in protecting your systems and data, they serve different purposes and are often 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.

What is authentication?

Authentication is the process of making sure the person trying to access your app is who they say they are. It's akin to showing your ticket at the entrance to a concert — authentication ensures that you are who you claim to be before granting access to a system's protected resources. This is the first line of defense against unauthorized access.

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.

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:

1. Time-generated OTPs — a new passcode is based on the current timestamp.
2. 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? 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).

What is authorization?

Authorization is the process that defines what a user can and cannot do in a system after their identity has been verified through authentication. Imagine it like using a key card in a hotel; the card allows you into your room and perhaps some common areas, but not into the hotel’s restricted service zones.

Authorization works by assigning permissions and policies to users, groups, or roles in a system. Permissions define what actions a user can perform on a resource, like read, write, or edit data.

Let’s pretend that we have an e-commerce store that sells socks. Our 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.
• 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.

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

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.

No matter which is your case, WorkOS, an all-in-one platform for quickly adding authentication and authorization to your apps, has you covered.

• Enterprise-ready authentication: From Single Sign-On, email/password AuthN, magic links, and multi-factor authentication, to social logins, WorkOS User Management has it all.‍
• Support every protocol: With OAuth 2.0 integrations of popular providers like Google and Microsoft, compatibility with every major IdP, and full support for custom SAML or OIDC connections, WorkOS can support any enterprise customer out of the box.‍
• Automatic user provisioning: Keep your app’s user data in sync with identity providers and directories. You can choose SCIM for ongoing synchronization or JIT (Just-in-Time) provisioning for on-the-fly provisioning at login.‍
• Authentication policies: Easily customize authentication policies for each organization you onboard.‍
• UI options: Use AuthKit, the customizable hosted UI with done-for-you authentication flows, or build your own and connect it to the user management APIs.‍
• Get started fast: With SDKs in every popular language, and Slack-based support, you can implement SSO in minutes rather than weeks.‍
• Avoid the back-and-forth: WorkOS’s Admin Portal takes the pain out of onboarding your customers’ IT teams and configuring your app to work with their identity provider.‍
• Pricing that makes sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard - whether they bring 10 or 10,000 SSO users to your app.‍
• Complete user visibility: Gain total visibility over your app’s user sessions through the WorkOS dashboard.
• Flexible, fast, and scalable fine-grained authorization: WorkOS Fine-grained authorization (FGA) is a centralized authorization service that you can use to implement a custom authorization model tailor-made for your application(s), with the ability to integrate elements of role-based access control (RBAC), relationship-based access control (ReBAC), and attribute-based access control (ABAC) as needed.

Explore User Management by WorkOS.