Every so often we hear the question: "Isn't authorization part of authentication?" Simply put, the answer is - no.

Authorization vs. Authentication

Authentication and Authorization are related, but they are separate concepts in the overall security model of an application:

• Authentication is the process of verifying that a user is who they say they are.
• Authorization is the process of verifying that a user is allowed to perform a certain action.

Authentication takes place before the user has any access to a protected system. We've all used authentication before - for example, when we log into a website, we are asked to enter a username and password. This is called Basic Authentication. More secure environments might use Two Factor Authentication (2FA) or Multi Factor Authentication, which are methods of authentication that are used to protect a user's account by requiring them to use additional devices to complete the authentication process. In any case, once the user provides the correct response to the authentication challenge, they are granted access to the system and their identity is verified.

For web applications, some information about the user's identity is stored in the browser using cookies or session storage. This ensures the user's identity is maintained across multiple pages and is not lost when the user closes the browser. This is how most applications ensure the user only has to log in once per session.

Authorization on the other hand, is a completely different beast. We can think of our application as a house with many rooms in it. In this metaphor - authentication is like the lock on the front door, and authorization is like the locks to each room within the house. Unlike authentication which happens only once per session - authorization happens every time a user tries to access any protected resource the application exposes.

At the point when authorization is done - we know who the user is: we let them through the front door and let them in the house. Now have to figure out if they're allowed to perform the action they're trying to perform.

To do this, the authorization system will have a mapping between all the resources exposed by the application to a set of actions that users may be able to perform on those resources. For example, a resource (customer, order, document) might be sitting behind a REST API endpoint, and the actions that a user may perform on that resource might be GET, POST, PUT, DELETE. A permission represents the ability to perform an action on a resource.

Users are granted access by having permissions assigned to their identity. It's very common that permissions are grouped into roles, and those can be assigned to users. This is known as the role-based access control model. For example, we can imagine a blogging website where a user can view a post, a moderator can view and edit a post and an admin can view, edit and delete a post.

In more complex scenarios, we might need a more fine-grained model, which will account for dynamic attributes users may have. That's when we can use attribute-based access control or relationship-based access control (either with roles or without them). For example, we can imagine a system where access to a resource is granted to a user if they are using a particular type of device or are trying to access the system from a particular location.

The difference between authentication and authorization has implications on how we design our application. For example, it's very common to use a hosted SaaS solution for authentication purposes, like Auth0, Okta, etc. Given that authentication only happens once per session - the added latency to an authentication request is nothing to worry about. As we mentioned before, authorization happens far more frequently in the application, and that means that a hosted SaaS solution is going to be a non-starter. We just can't afford the latency added to every request, not to mention having to fail that request if the authorization API is down .

Authentication code is mostly isolated from the rest of the application code. That makes it easier to maintain, update or replace if necessary. Authorization logic, on the other hand, is usually tied to the rest of the application code, simply because it gates particular actions that take place in various places in the codebase. This makes authorization a more complex problem to tackle - compared to authentication.

To summarize: Authentication and authorization are related but separate processes in the overall security model of an application. One asks "who the user is?" and the other "what is the user allowed to do?". Each of these processes is subject to a different set of considerations and requirements. Unlike authentication, there are very few authorization standards, and so it continues to be an open problem that a lot of developers choose to tackle from scratch. Luckily, Aserto can help! Sign up to learn more.