“Auth” is the shorthand term that many people use to describe the process of Authentication and Authorization. These processes are often confused with each other or conflated together. Even experts sometimes get this wrong!

Here’s a real-world analogy that explains the difference between authentication vs authorization and motivates you to think of them as separate processes.

Authentication in real life

When you check into a hotel, you present your ID to authenticate yourself to the front desk. Authentication is the process of proving that you are who you say you are. In the real world, you do this using an ID that was issued by a trusted third party, such as a government agency.

The hotel staff treats your ID as proof that you are in fact who you say you are. They will trust that your legal name is as it appears on the ID, because they trust the issuer of that ID. They’ll look up your reservation by that name, and verify that you did in fact make one. They’ll also find out more about you - for example, whether you’re a member of their loyalty club, and at what level.

Authentication in the digital world

In the digital world, the process is a bit more complex, since we don’t have universal digital identities. Instead, each web application (or site) has to manage identities themselves. When you register with a web app, you provide at least two pieces of information - a unique identifier (often an address where you can obtain messages, such as an email or phone number), and a secret that is shared between you and the application (traditionally, a password).

When you come back to the application, it authenticates you by asking for both the identifier (e.g. email) as well as the secret. The secret can be a password, a biometric, or a magic link. For further security, the application may send you another code at your address (via email or text), a process known as multi-factor authentication (MFA).

You go through this dance because there isn’t a universal identity system for the internet. The closest approximation we have are large-scale trusted authentication systems from big tech companies, like Google and Facebook. Applications sometimes allow you to sign in using these “social” logins, relying on them to authenticate the user, and trusting the results. Fortunately, there are plenty of developer platforms, such as Auth0, Stytch, Clerk, and others that make it easy to wire in authentication without having to build it all yourself.

Whether you have your own authentication system or rely on someone else’s, that system is known as an Identity Provider (IDP).

Now, back to our hotel check-in process!

Authorization in real life

Once they look up your reservation and verify that it’s valid, the front desk staff issue you a keycard.

Your keycard gives you access privileges that depend on who you are. It will allow you to take the elevator up to your floor (but perhaps no other floor). It’ll also unlock your room, but not anyone else's room. It will let you enter the gym or swimming pool, but only during the hours they are open.

If you’re a gold member of the hotel's loyalty club, your card will allow you to take the elevator to the executive club level, and into the room that serves your free breakfast.

In other words, Authentication is the process of exchanging your proof of identity (and a valid reservation) for a key that lets you unlock some (but not all) doors. And Authorization is the process of checking whether that key unlocks the specific door you’re trying to open.

An important thing to remember is that different cardkey holders (hotel guests and hotel staff) have different access privileges that must be enforced. Indeed, if you get locked out of your room, a staff member can let you in with a card that looks the same as yours, but has some extra privileges - it unlocks every room.

Authorization in the digital world

In the digital world, access privileges are often represented using access tokens. These are strings of information that are cryptographically signed by an issuer. Often that issuer is the same Identity Provider (IDP) that performed the authentication process. This is why Authentication and Authorization are so often confused with each other!

An access token can contain claims, such as “the bearer of this token is an admin and can open all doors,” or “the bearer of this token can open the door for room 12345.” Access tokens can be used to provide a simple form of authorization, but they also have some limitations: granularity, size, freshness, and dynamism.

Granularity and size

Since access tokens are often transmitted as HTTP headers, there are limits on how big they can get. In our hotel example, our access token will likely be reasonably small, since every hotel guest is only allowed a small number of discrete privileges. Conceptually, if the hotel had a tour group who bought out a whole wing, and had keys issued to the organizers that could open dozens of doors, you may run into size issues.

A much more obvious example is a document management system that secures thousands (or millions) of documents. For a system like that, it’s impractical to load up an access token with references to all of the documents that the user can access.

Freshness

Just like a hotel cardkey, an access token has an expiration. But what if you lose the cardkey, and you need to have the front desk generate you a new one? They invalidate the old one, so that if someone finds it and tries to unlock your door, they won’t be granted access to your room. It’s clear that the lock can be remotely programmed by the front desk, and evaluates the information on the keycard in real time against the information it is programmed with.

Access tokens (also known as bearer tokens) are often treated as self-sufficient: as long as the access token hasn’t expired, it is a valid representation of the privileges of a user. But this doesn’t allow for revoking privileges. It’s clear that just like the lock on your room door, a truly secure system needs to evaluate the user’s privileges in real-time - that is, right as the user is trying to unlock the door.

Dynamism

As already mentioned, it’s impractical to embed references of every resource the user can access into the IDP-issued access token. In addition, many systems are very dynamic with respect to what the user has access to. For example, a support ticket system can have many new tickets opened (and closed) every hour, so a support agent will have a constantly shifting set of privileges.

This doesn’t happen with hotel rooms very often - guests don’t gain or lose access to rooms throughout their stay. But it happens all the time in digital systems: in a large organization, users may be granted (or revoked) access to many resources (such as documents) many times a day.

Identity providers are built to perform authentication once per session. They don’t know anything about what resources a user is granted access to, and even if they did, they aren’t architected to issue new access tokens with that information.

Fine-grained, real-time authorization

To sum up, access tokens are simple, but have a number of limitations that make them impractical to use for “real” authorization - which often includes requirements around granularity, freshness, and dynamism. Fortunately, a new type of digital authorization system is emerging which can handle these real-world scenarios.

Authorization service

Architecturally, a fine-grained authorization service picks up where the identity provider leaves off. Its function is to provide an answer to the question “does this user have this permission on this resource?”

It needs to answer that question to arbitrary levels of granularity: if resources are organized in a hierarchy (for example, tenants → projects → lists → items), access may be granted at any level of the hierarchy, with items having their own access control lists, but also inheriting permissions from lists, lists from projects, and projects from tenants.

And it needs to answer that question in real-time: does this user have access to this resource now. Rather than relying on a potentially stale claim in an access token issued hours ago, the authorization service has a real-time view of all of the permission assignments in the system.

How Authentication and Authorization work together

Architecturally, the authorization service performs its function downstream from the identity provider, which authenticates the user.

At login, the IDP is responsible for performing the authentication dance, and provides the application with an access token that minimally contains the identity of the user, encoded as a “subject” claim. It may also provide some other basic claims (for example, the organization the user belongs to in a multi-tenant application).

When it comes time to determine whether to grant the authenticated user access to a resource, the application makes a call to the authorization service. The access token returned by the identity provider can be passed to the authorization service as proof of the user’s identity, while the permission level and specific resource are passed in separately.

The authorization service then looks up the user, permission, and resource in its own data store, and returns an “allow” or “deny” decision.

Authorization must be a local operation

While user login happens once a session, authorization happens in the critical path of every application request. This means that authorization has to be a low-latency operation that is 100% available to the calling application. For that reason, authorization services have to be deployed close to the application itself.

In our real-world analogy, imagine a door lock that called an authorization service deployed somewhere on the internet every time a hotel room guest tried to swipe their card key into the reader. If the service was down, or the internet connection was down, the guest couldn’t enter their room!

This is exactly why each door lock must perform authorization decisions autonomously, without requiring access to a remote system.

Authorization data needs to be managed centrally

At the same time, the door lock must be remotely programmable - the front desk must be able to send a door lock new codes. This is why authorization requires a distributed systems architecture: authorize locally using a local, fresh copy of data that is managed centrally.

Conclusion

In this article, we examined what makes up “Auth” - the two related but separate processes of Authentication and Authorization. We also discussed why authentication systems cannot perform real-world authorization. Requirements around granularity, freshness, and dynamism transform authorization into a separate architectural layer.

Fortunately, there are a growing number of fine-grained, real-time authorization platforms available for developers that don’t want to have to build it all from scratch. To discuss your authorization challenges, reach out to us to schedule a call with an engineer, or chat with us on Slack!