Skip to main content
Authentication Systems Tutorial
CHAPTER 02 Intermediate

Understanding Authentication vs Authorization

Updated: May 14, 2026
20 min read

# CHAPTER 2

Understanding Authentication vs Authorization

1. Introduction

The terms "Authentication" and "Authorization" are often used interchangeably by beginners, but in backend engineering, confusing the two will lead to catastrophic security breaches. They represent two completely distinct phases of security. In this chapter, we will definitively separate these concepts, define access control, and introduce the concept of User Roles and Permissions.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Clearly articulate the difference between Authentication (AuthN) and Authorization (AuthZ).
  • Understand the chronological flow of a secure request.
  • Define what a "Permission" is.
  • Understand the concept of "User Roles" and Access Control.

3. Beginner-Friendly Explanation

Let's return to the hotel analogy. Authentication (AuthN): You walk up to the front desk. You hand the receptionist your ID. The receptionist verifies your face matches the ID. You have been Authenticated. The receptionist hands you a plastic keycard. *You have proven WHO you are.*

Authorization (AuthZ): You take your keycard and walk to the 5th floor. You try to swipe your keycard on the door to the gym. The light flashes green; the door opens. You try to swipe your keycard on the door to another guest's room. The light flashes red; the door stays locked. *The system has checked WHAT you are allowed to do.*

If you are Authenticated, you are allowed inside the building. If you are Authorized, you are allowed inside a specific room.

4. Authentication (AuthN)

  • Goal: Verify identity.
  • Question Answered: "Who are you?"
  • Mechanism: Passwords, Biometrics, OTPs (One-Time Passwords).
  • Result: The system generates a Session or a Token indicating you are a valid user.

5. Authorization (AuthZ)

  • Goal: Enforce permissions and access control.
  • Question Answered: "Are you allowed to do this specific action?"
  • Mechanism: Checking User Roles (Admin vs. User), checking resource ownership (Did you write this post?), reading Access Control Lists (ACLs).
  • Result: The system executes the requested action OR throws a "403 Forbidden" error.

6. The Chronological Security Flow

When a user attempts to delete a blog post, the backend server must execute these steps in order:
  1. 1. AuthN Check: Is the user logged in? (If no -> Return 401 Unauthorized).
  1. 2. AuthZ Check: Is the user an Admin, OR did the user write this specific post? (If no -> Return 403 Forbidden).
  1. 3. Execution: Delete the post from the database.

*Critical Failure:* If a developer forgets Step 2, a logged-in user could delete another user's post. This is called a Broken Access Control vulnerability, and it is the #1 security flaw on the internet.

7. Roles and Permissions

To manage Authorization at scale, systems group permissions into Roles.
  • Permission: A specific action. (e.g., can_delete_users, can_publish_articles, can_view_dashboard).
  • Role: A container of permissions. (e.g., The Moderator role contains can_publish_articles and can_view_dashboard, but NOT can_delete_users).

When a user is created, they are assigned a Role. The software checks the Role before granting access.

8. Real-World Code Example (Express.js)

Here is how AuthN and AuthZ look when written as middleware in an Express.js API.
javascript
12345678910111213141516171819202122232425
// 1. AUTHENTICATION (AuthN): Check if they have a valid token (Keycard)
function requireAuthentication(req, res, next) {
    const userToken = req.headers.authorization;
    if (!userToken) {
        return res.status(401).json({ error: "AuthN Failed: Please log in." });
    }
    req.user = decodeToken(userToken); // Identify the user
    next(); // Proceed to the next step
}

// 2. AUTHORIZATION (AuthZ): Check if their Role allows this action
function requireAdminRole(req, res, next) {
    // We already know WHO they are (AuthN passed), now we check WHAT they are.
    if (req.user.role !== 'admin') {
        return res.status(403).json({ error: "AuthZ Failed: Admins only!" });
    }
    next(); // Proceed to execution
}

// The Route applies both security layers in chronological order!
app.delete('/api/users/:id', requireAuthentication, requireAdminRole, (req, res) => {
    // If we reach this code, the user is proven to be logged in AND an admin.
    database.deleteUser(req.params.id);
    res.json({ message: "User deleted successfully." });
});

9. Best Practices

  • Principle of Least Privilege: A user should only be given the absolute minimum permissions necessary to perform their job. If an employee's job is just to write blog posts, they should not be given an "Admin" role just because it's easier to configure.

10. Common Mistakes

  • Confusing 401 and 403 HTTP Codes:
  • 401 Unauthorized actually means "Unauthenticated." The user is not logged in.
  • 403 Forbidden means "Unauthorized." The user IS logged in, but they lack the permissions to view this specific page.

11. Exercises

  1. 1. Define the terms AuthN and AuthZ. Which one must always occur first chronologically?

12. Coding Challenges

  • Challenge: Write a PHP or Python pseudo-code function named delete_comment(user_object, comment_object). Write the if statements required to implement authorization. The user should only be allowed to delete the comment IF user_object.role == "admin" OR user_object.id == comment_object.author_id.

13. MCQs with Answers

Question 1

Which of the following scenarios is a failure of Authorization (AuthZ) rather than Authentication (AuthN)?

Question 2

Which HTTP status code should a backend server return if a user is successfully logged in, but attempts to access a resource reserved strictly for Administrators?

14. Interview Questions

  • Q: Differentiate between Authentication and Authorization. Provide a real-world software example illustrating how a failure in Authorization could lead to a data breach even if Authentication is perfectly secure.
  • Q: Explain the "Principle of Least Privilege" in the context of designing an Access Control system.

15. FAQs

Q: Can a system have Authorization without Authentication? A: Technically, yes, but it's rare. For example, a public website might allow "Guest" users (no authentication) to read articles, but prevent them from posting comments. The system is authorizing the "Guest" role to perform Read actions, but denying Write actions.

16. Summary

In Chapter 2, we clarified the crucial distinction between Authentication (verifying identity) and Authorization (verifying permissions). We mapped the chronological flow of backend security, demonstrating that the system must first answer "Who are you?" before it can answer "Are you allowed to do this?". We explored the concepts of Roles and the Principle of Least Privilege, and viewed how these concepts are physically implemented as sequential middleware in a web API.

17. Next Chapter Recommendation

We understand the theory; it is time to build the foundation. Proceed to Chapter 3: Building Basic Login and Registration Systems.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·