Authentication vs. Authorization, What's the Difference?
On this page
The terms "authentication" and "authorization" are often mistakenly used interchangeably. However, they refer to two distinct security processes: authentication is the act of verifying a user's identity, while authorization determines what resources or actions the authenticated user is permitted to access. Understanding the difference between the two is essential for designing secure systems and enforcing proper access controls. This article explains what each term means and how they differ.
What is Authentication?
Authentication is the process by which a system authenticates a user. Usually, this will mean verifying that the user currently accessing the system is the same user who accessed it before. Some systems, however, might require stronger authentication and also check the user's physical identity — who the user is in the real world. The goal is to establish a level of trust between the user and the application before granting access to the system. For the system to trust the user, the user must present some form of identification, a credential, or proof of their identity. The type of this proof is defined by the authentication method. Traditionally, this has meant entering a username and password. However, modern systems increasingly rely on stronger mechanisms, such as multi-factor authentication, passwordless authentication, or even public key cryptography, to enhance security and reduce the risks of credential-based attacks.
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 identifies the user, and the password proves that this is the given user that accesses the system. 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
To strengthen access security, many systems use two-factor authentication (2FA) and multi-factor authentication (MFA). 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:
- 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 Authentication
Modern implementations of user authentication are moving towards passwordless solutions. 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 passkeys, which offer a passwordless and convenient way to log in to online accounts and services.
Token-based Authentication with OpenID Connect
Modern applications often reply on OpenID Connect (OIDC), an identity layer built on OAuth 2.0, for token-based authentication. OIDC allows applications to outsource the authentication process to 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. Other systems can then use this token to check the user's identity, which enables Single Sign-On (SSO) across multiple services.
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. Once the system authenticates a user, it must decide whether the user can access certain features, data, or functionality. This is the essence of the authorization process.
There are several types of authorization models:
Access Control List (ACL)
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.
Role-Based Access Control (RBAC)
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 for RBAC to suffer 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.
Attribute-Based Access Control (ABAC)
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 with OAuth 2.0
Token-based authorization is a mechanism where systems rely on tokens (short-lived access credentials) to perform authorization — as opposed to using API keys, or relying on information provided in the request's headers or body. When using OAuth 2.0, the authorization server authenticates the user with the help of an identity provider (which might be the same component) and issues access tokens that contain scopes and claims.
When the application sends a request with the token, the backend system uses it to perform authorization decisions. It uses scopes to limit which parts of the system the user and the requesting application should have access to. For example, a request from a customer application will not be able to read data from an endpoint meant for customer support. The backend system then uses claims to perform fine-grained authorization. For example, an API can use the user ID claim to filter the user's database entries before returning them in a response.
Conclusion
Understanding the difference between authentication and authorization is an important prerequisite for building secure digital systems. 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 prove identity of the user when communicating with backend systems. After authentication, when the user is known, a set of scopes and claims is 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
Frequently Asked Questions
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
