Authentication vs. Authorization, What’s the Difference?
On this page
The terms authentication and authorization are sometimes used interchangeably. Authentication is the process of verifying a user's identity, while authorization determines what resources or actions that authenticated user is allowed to access. Though the terms are sometimes used interchangeably, authentication is a prerequisite for implementing authorization. This article outlines what each one of these terminologies means and what's different between the two.
What is Authentication?
Authentication defines the practice of verifying that the user is who they say they are. The goal is for an application or service to trust that the user interacting with the system is indeed who they claim to be. In order for the system to trust the user, the user needs to present some level of proof of who they are. How to provide this proof is defined by the authentication method. Traditionally, users provide a username and password, but modern system base their authentication on public key cryptography.
Examples of Authentication
Username and Password
The most common way of authentication is to have the user provide a username and a password. The username is used to distinguish users from each other, i.e., identify them, and the password serves as the proof. The username might be more or less publicly known or at least reasonably easy for an attacker to figure out. Since the username serves as the identifier it needs to be unique. For that reason, it is common to use the user's email address as the username.
The password is the shared secret between the user and the system the user is authenticating to. The user presents the password, and the application has the user's password stored in some persistent storage, typically in a hashed format and not in clear text. To verify the password the application first hashes the password that the user is presenting and then compares that hashed representation with what's stored in the database. If the hashes match, the password presented by the user is correct and the authentication is successful.
The use of passwords for authentication is fairly easy to implement but has its issues. Passwords can be difficult to protect, easy to guess if they are weak and most users can't remember unique passwords for all applications they use and end up reusing the same password for multiple applications. If one application is breached and with that the user's password, the attacker could potentially pose as that user to multiple applications or services.
Two-Factor and Multi-Factor Authentication
Both two-factor and multi-factor authentication was introduced in order to strengthen the security for authentication. If username and password is a single factor of authentication, something you know, a second factor can be added and could for example be something you have. Early on, the second factor was commonly some type of hardware authentication device or dongle. Today, using multiple factors for authentication is a common approach. Some examples of additional factors that can be used in combination (in addition to a password) are:
- Geo-location information
- Biometric information
- SMS code or link
- Email code or link
- Hardware device (such as YubiKey)
- Authentication applications
- Push notification
- One-time-code
- Challenge/Response code
Passwordless
Modern implementations of user authentication are moving towards passwordless authentication. This might seem strange given that it started with a username and a password, then moved to adding an additional factor and later even multiple factors. Passwordless authentication does not however mean that the user will not present proof that they are who they say they are. It's just not done using a password. The rationale is that the password is easily compromised. Instead, passwordless uses, SMS, email, a dedicated passwordless application or a hardware token to name a few. One of the most robust ways to authenticate a user is to leverage WebAuthn as it is a phishing proof approach to authenticating the user, or passkeys which offer a passwordless and convenient way to log in to online accounts and services.
Token-based Authentication
Modern applications typically don't handle authentication internally but instead leverage an external system, an identity provider (IdP). An IdP is a service that is responsible for authenticating users and can typically do so using any of the aforementioned methods. If authentication is successful, the application receives a trusted response from the IdP, a token. This token is bound to the user and can be used to verify the authenticated user. It has a limited lifespan and when the token expires, the user needs to authenticate again.
This helps applications to not have to manage sensitive user information and thus reduces the risk of a data breach. Additionally, it allows different applications to share the same authentication system so users do not have to remember multiple sets of credentials.
Identity Proofing
Usually, the goal of authentication is to verify that the returning user is the same user that previously engaged with an application. The actual, physical identity of the user is not relevant — systems just want to ensure that it is the same user, not who the user really is. For some use cases, however, this is not enough, and there are applications that require greater proof of some actual user data. For example, applications can use systems that verify the user's ID documents to confirm the user's physical identity. In other cases, it might be required to check whether the user represents a legitimate business entity. In such an instance, the user's claim can be verified against a company database to verify the legitimacy of the business entity. Integrating with external systems allows companies to prove the correctness of many different types of user data.
What is Authorization?
Authentication is a prerequisite to Authorization. Authentication determines who the user is and that they are in fact who they claim to be. Authorization on the other hand is the practice of determining if the user is allowed to perform certain actions within the system or access certain resources or data. Authorization is usually implemented using an Access Control List (ACL), Role Based Access Control (RBAC) or Attribute Based Access Control (ABAC).
ACLs defines a static list of permissions that's assigned directly to the user. This is not a very flexible approach, nor does it scale in large environments with lots of users.
With RBAC, permissions are mapped to roles. When a user is attempting to perform certain actions or access certain resources, the system will validate the user's roles and their associated permissions to see if they are allowed to perform the action on the given resource. If the user is allowed, then the system grants access, if not the system denies access. RBAC is a very common approach to authorization, but it does come with its own issues. It's not uncommon that RBAC suffers from role explosion. This is when the number of roles grow, sometimes even beyond the number of users. This is a result of having to define common roles within an organization but also having to cover any and all corner cases and exceptions to the standard roles defined.
ABAC is a modern approach where attributes are leveraged in conjunction with a policy to determine authorization. This is a more dynamic approach as the specific entitlement is "calculated" at runtime based on attributes as input and a policy that is in use by a policy decision engine, also typically known as a Policy Decision Point (PDP). This overall system is also known as an Entitlement Management System (EMS).
With ABAC it's possible to express relational authorization where a policy could define something similar to userId == account.owner. This allows for very fine-grained authorization to be expressed that cannot be done using ACLs or RBAC. Another advantage of ABAC is that it is typically handled by an external service (the PDP) and thus can be consumed and used by many different applications and services making the authorization policy easier to manager as a whole.
Token-based Authorization
Token-based authorization is a mechanism where authorization is handled using tokens. An IdP authenticates the user and authorizes the client application delegated access to the resource server by issuing a token. The client can request a set of scopes that indicates what access is requested. The issued token will contain a set of scopes and claims that can be consumed by the resource server in order to determine what data is authorized.
This could be combined with an EMS where the resource server (or a proxy in front of the resource server) sends the token and additional attributes as needed to a PDP that responds with the authorization decision. The token holds a set of claims with values (attributes) that are used together with additional attributes from the request or other data sources and are applied to a policy to determine an authorization decision.
Conclusion
Authentication and authorization are an important part of modern application security. Having an effective authentication and authorization mechanism can ensure the security of user data and prevent unauthorized access to the application. Token-based authentication and authorization works in unison to first verify the user and then issue a token. The token is then used by the application to proof identity of the user when communicating with backend systems. After authentication, when the user is known, a set of scopes and claims are issued in the token. Scopes and claims are used by the resource server to determine what the user is authorized to access.
Jonas Iggbom
Director of Sales Engineering at Curity
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
Start Free Trial
