Authentication (authN) and authorization (authZ) have a lot in common. Both play critical roles in identity and access management. Both have a big impact on user experience for a website or app. And, obviously, they look and sound pretty similar.
But the parallels end there. Actually, authentication and authorization serve very different purposes—and they shouldn’t be confused or used interchangeably.
Below, we explore the differences between authN and authZ and explain how they work together (but separately) as part of your application architecture.
What is authentication?
Authentication is the process of verifying a user is who they claim to be. A user can prove their identity by providing something they know (such as a password or personal data), something they have (like a mobile device, security token, or digital ID card), or something they are (biometric data including fingerprints, retinal scans, and facial recognition).
Traditionally, authentication has relied on basic passwords and PINs, which come with significant security and UX concerns. As online security evolves and becomes more sophisticated, forward-thinking companies are switching to passwordless authN methods such as SMS one-time passcodes, email magic links, biometrics, and more.
Depending on your business’ requirements and the sensitivity of the user data you work with, you have a range of authentication methods to choose from. Here are three main types, in order from least to most secure:
- Single-factor authentication: Only one layer of credential verification is required, such as a username and password.
- Two-factor authentication (2FA): A user must supply a password plus a secondary verification factor, which could be anything from an additional security question (e.g. the classic “What’s your mother’s maiden name?”) to an SMS one-time passcode or biometric.
- Multi-factor authentication (MFA): Two or more levels of independent security are required. Two-factor authorization (above) is an example of MFA, but not all MFA is 2FA.
What is authorization?
Once a user is authenticated, the authorization process verifies what they are permitted to do—or not permitted to do—on an app or website. Authorization grants access to specific resources or data within an environment or unlocks actions like viewing, editing, downloading, or deleting data.
User permissions are determined through several authorization models:
- Role-based access control (RBAC): Access to information is based on the user’s role within an organization.
- Attribute-based access control (ABAC): Access to information is limited and based on a more complex series of attributes, such as:
- User attributes, including name, role, organization, ID, and security clearance
- Environmental attributes, including time, location, and current organizational threat
- Resource attributes, including owner, file name, and level of data sensitivity
- Rule-based access control (also RBAC): Access is allowed or denied based on standardized rules rather than the user or role.
Key differences between authentication and authorization
There’s a common analogy used to understand the main difference between authN and authZ.
Think of it like an airport. When you go through security, you provide a boarding pass and official identification like a driver’s license or passport. These two factors prove that you are allowed to enter the terminal. That’s authentication.
After that, the details on the boarding pass determine where you can go. You can show your pass to board the plane and take your assigned seat—but if you try using it to get on a different flight or to gain access to an employee-only area, you’ll be denied. That’s authorization.
In addition to having separate functions, authN and authZ are dissimilar in the role a user plays:
- Authentication is visible to the user. The user can also partially change the authentication settings—by resetting a password, altering security questions, or providing biometric data.
- Authorization is rarely a user-facing process. Permissions are pre-set and maintained on the back-end by the organization.
Let’s break these differences down into one easy chart for comparison:
Combining authN and authZ with session management
Authentication and authorization work in tandem to create a secure environment for both the user and the website or app.
In a standard flow, authN comes first, followed by authZ. One component of authorization is session management which can be used to determine if a user is still logged in or if their session has expired and is often coupled with the permission data about what the user can access.
Session management is the process of storing context around a given logged in user. Session management can store context around a user, even pre authentication. A logged out session might be used to track things such as localization data. Once a logged in session has been established after a user completes authentication; the session is responsible for storing context such as the length of session and the user’s permissions. A session can expire after a set amount of time or after a specific action such as a user logging out.
Now that you can distinguish between authN and authZ, the next step is finding the right passwordless solutions to fit your needs. That’s where Stytch comes in.