Authentication (authN) and authorization (authZ) have a lot in common, which is why they’re often confused. Both play a key role in user identity and access management (IAM), both have a big impact on the user experience, and as words, they look and sound pretty alike.

But the parallels end there. In fact, authentication and authorization serve very different purposes, though each is essential when it comes to protecting your app. Ideally, it shouldn’t be “authentication vs. authorization,” but both “authentication and authorization.”

In this post, we explore the key differences between these two critical processes and explain how they work together (but separately) as part of your app’s security architecture.

What is authentication?

At the most basic level, authentication verifies a user’s identity, ensuring a user is who they claim to be before they gain access to an app. Typically, a user must provide one or more authentication factors (or credentials), which can fall into three different categories:

• Something-you-know, like a password or personal detail
• Something-you-have, like proven possession of a registered mobile device, security access token, or digital ID card
• Something-you-are, like biometric data from fingerprints, retinal scans, facial recognition, or voice recognition

The authentication process

Historically, the user authentication process relied on basic factors like passwords and PINs, which can cause significant cybersecurity gaps and UX concerns. (Case in point: today, over 80% of data breaches come from stolen or otherwise compromised passwords).

But as the online security process has evolved and grown more sophisticated, forward-thinking companies have increasingly switched to passwordless authentication methods, like one-time passcodes, email magic links, and biometrics.

Depending on your business needs and the sensitivity of the user data you work with, there’s a wide range of methods you can use to build out your authentication system. The three main types, from least to most secure, are:

Single-factor authentication

In a single-factor flow, only one layer of verification is required — for example, a username-and-password pair.

Two-factor authentication (2FA)

In a two-factor flow, a user must supply a password plus a secondary credential, which could be anything from a security question (e.g., the classic “What’s your mother’s maiden name?”) to an SMS one-time passcode.

Multi-factor authentication (MFA)

In a multi-factor authentication (or MFA) flow, two authentication factors or more are required. That means 2FA is considered MFA, but not all MFA flows are 2FA.

Multi-factor authentication can be front-loaded at initial log in — meaning users must pass through all authentication steps at once just to enter an app — or they can be spread throughout the user journey. The latter method is known as just-in-time authentication, as it allows developers to introduce extra security steps (and thus, extra friction) only when a user attempts to access sensitive information or carry out a sensitive task, like changing payment details or viewing confidential data.

What is authorization?

After a successful authentication, authorization verifies what a user is permitted — and not permitted — to do within the app. In other words, user authorization processes grant access rights to specific resources and give a user permission to undertake specific actions like viewing, editing, downloading, or deleting important data.

How authorization determines access control

Access control, or unique user permissions, can be structured in a few different ways:

Role-based access control (RBAC)

In a role-based model of control, access to information is based on the user’s position within an organization.

Attribute-based access control (ABAC)

In an attribute-based model, access to information is limited and based on a complex series of factors, potentially including:

• User attributes, such as name, organization, ID, and level of security clearance
• Environmental attributes, such as the time or location of access or the current level of organizational threat
• Resource attributes, such as a file’s owner or department or its level of data sensitivity

Rule-based access control (also RBAC)

In a rule-based access control model, user access is determined by fixed, standardized guidelines, rather than subjective or variable criteria.

Authentication vs. authorization: key points of difference

There’s a common analogy used to explain the difference between authentication and authorization: think of it like an airport. When you pass through security, you’re asked to provide a boarding pass and formal identification like a driver’s license or passport. These two factors prove that you’re allowed to enter the terminal. That’s authentication.

Once you’re in the terminal, the details on the boarding pass determine where you can go. For example, you can use your pass to board your plane and take your assigned seat, but if you try to get on a different flight or gain access to an employee-only area, you’ll be denied entry. That’s authorization.

In addition to having separate functions, authentication and authorization differ in the role played by the user:

• The authentication process is visible to the user. The user can also change certain authentication settings by resetting a password, modifying security questions, or choosing to register biometric data.
• The authorization process is rarely user-facing. Rather, 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 authentication and authorization with session management

Authentication and authorization work in tandem to create a secure environment for both the end user and the app or website they’re using. In a standard flow, authentication comes first, followed by authorization.

One component of authorization is session management, or the process of storing contextual information for a given user. For example, session management can be used to determine if a user is still logged in or if their session has expired, and it’s often coupled with permissions data about what that authenticated user can and cannot access.

Typically, that permissions data is stored either with session cookies or access tokens (typically JSON web tokens, or JWTs). At Stytch, we let you use both, but if you want to dive deeper you can read our blog on the differences and tradeoffs between session cookies and JWTs.

The bottom line

“Authentication vs. authorization” is a bit of misnomer – both contribute substantially to your app’s IAM. Together, authentication and authorization ensure you grant secure access to the right users at the right time.

Take your auth up a notch with Stytch

Now that you can distinguish authentication vs. authorization, the next step is finding a security flow that fits your needs. That’s where Stytch comes in. Our passwordless product suite and breach-resistant Passwords strike the perfect balance between robust protections and a frictionless user experience.

Register for a free account to begin exploring — or reach out to our team to get your questions answered.