Authentication vs. Authorization

1. Who Are You vs. What Can You Do?

At the heart of application security lie two fundamental questions:

1. Authentication: "Who are you?" This process is about verifying a user's identity.
2. Authorization: "What are you allowed to do?" This process determines the permissions of an authenticated user.

Authentication always comes before authorization. A system needs to know who you are before it can decide what you can access.

A common and effective analogy is airport security.

• When you show your passport or ID to the security agent, you are authenticating yourself. You are proving that you are the person you claim to be.
• Later, when you show your boarding pass at the gate, the airline staff is authorizing you to board the plane. The boarding pass grants you permission to access a specific resource (a seat on Flight 123) but not any other flight.

To get a solid grasp of these definitions and see a helpful comparison, please read the following sections from an article by Auth0, a major player in the identity management space.

2. How Authentication Works: Proving Your Identity

As you've just read, authentication is the process of validating a user's claim to an identity, typically by checking credentials. Let's explore this in more detail.

The evidence used for authentication is called an authentication factor. These factors are generally categorized into three types:

• Knowledge factor: Something only the user knows (e.g., a password, a PIN).
• Possession factor: Something only the user has (e.g., a physical key, a mobile phone for receiving a one-time code).
• Inherence factor: Something the user is (e.g., a fingerprint, a facial scan).

You've likely encountered different authentication schemes based on these factors:

• Single-Factor Authentication (SFA): Uses only one factor, like a password.
• Two-Factor Authentication (2FA): Requires exactly two factors, like a password and a code from your phone.
• Multi-Factor Authentication (MFA): Requires two or more factors from different categories (e.g., a password (knowledge) and a fingerprint (inherence)).

For a deeper dive into these concepts and how they fit into modern security standards, please read the following material. As you read, notice the mention of JSON Web Tokens (JWTs), which we will cover in detail in our next lesson.

3. How Authorization Works: Granting Permissions

Once a user is authenticated, the system knows who they are. The next step is to determine their permissions—this is authorization. Authorization is essentially an access control mechanism based on a set of rules or policies.

For a simple application, you might define permissions for each user individually. However, this doesn't scale well. Imagine managing permissions for thousands of users across hundreds of resources in a large company. It would be an administrative nightmare.

This is where authorization models come into play. A common and powerful model is Role-Based Access Control (RBAC). In RBAC, instead of assigning permissions directly to users, you assign permissions to roles (e.g., "admin", "editor", "viewer"), and then assign users to those roles.

This video from Professor Messer, a well-known cybersecurity educator, clearly explains the challenge of scaling permissions and how RBAC solves it.

4. A Practical Web Development Example

Let's tie these concepts to a typical web application flow, which should be familiar given your background in web development.

Consider a simple API built with a framework like Node.js/Express (the principles are identical for Next.js API routes).

1. Authentication Step:

   • A user submits their email and password to a /api/login endpoint via a POST request.
   • The server-side code checks if these credentials match a record in the database.
   • If the credentials are valid, the user is authenticated. The server then generates a token (often a JWT) containing the user's ID and role (e.g., { userId: 123, role: 'admin' }). This token is sent back to the client.

2. Authorization Step:

   • The user wants to fetch some protected data, for example, by making a GET request to /api/data.
   • The client application includes the token from the login step in the Authorization header of the request.
   • The server-side code for the /api/data endpoint first verifies the token. If the token is invalid or expired, it rejects the request (an authentication check, in a way, as the identity proof is no longer valid).
   • If the token is valid, the server now knows who the user is (e.g., user 123). It then performs an authorization check. For instance, it might query the database for data WHERE ownerId = 123, ensuring the user only sees data they own. If the user tried to access an admin-only endpoint, the server would check for role: 'admin' in the token before granting access.

This flow clearly separates verifying identity from checking permissions, using a token as the bridge between the two.

Conclusion

In this lesson, we've established the clear distinction between authentication and authorization, two cornerstones of application security.

Key Takeaways:

• Authentication is about verifying identity ("Who are you?"). It's the first step in any secure process.
• Authorization is about granting permissions ("What are you allowed to do?"). It happens after a user has been successfully authenticated.
• Authentication uses factors like passwords or biometrics, while authorization uses policies and roles (like RBAC) to control access.
• Both are critical and work together. Strong authentication prevents unauthorized users from getting in, and strong authorization limits what an authenticated user can do, minimizing potential damage.

In our next lesson, we will dive into the technology that often links these two processes in modern web applications: JSON Web Tokens (JWTs). We'll explore the structure of a JWT (header, payload, signature) and understand how it securely transmits identity and permission information after a user has been authenticated.