CodingNic
Sign In Book Session

Authorization & Roles

Authentication vs. Authorization

Authorization & Roles 10 min read

Authentication vs. Authorization

Objectives

By the end of this lesson, you should be able to:

  • State the precise difference between authentication and authorization
  • Explain why a logged-in user isn’t automatically an authorized one
  • Identify the correct status code for each kind of failure

💡 Why this matters: Modules 2 and 3 built authentication, proving who’s making a request. This module builds something different on top of it, deciding what that verified identity is actually allowed to do.

Two Different Questions

Authentication asks: who is this? Modules 2 and 3 answered this, a valid session or a valid JWT proves a request comes from a specific, verified user.

Authorization asks a completely different question: is this specific person allowed to do this specific thing? A logged-in user is definitely someone, that doesn’t mean they’re allowed to delete another user’s account, view another user’s private data, or access an admin dashboard.

Why Conflating Them Is a Real Bug

javascript
app.delete('/api/v1/users/:id', requireAuth, (req, res) => {
  // deletes the user, as long as *someone* is logged in
});

This route checks authentication (requireAuth) but never checks authorization at all, any logged-in user, regardless of role, could delete any other user’s account, including one that isn’t theirs. This is a genuine, common vulnerability class, not a hypothetical one, missing authorization checks show up regularly in real security audits.

The Two Failure Modes Have Different Status Codes

  • 401 Unauthorized means authentication failed, no valid session or token at all, “I don’t know who you are.”
  • 403 Forbidden means authentication succeeded, but authorization failed, “I know exactly who you are, and you’re not allowed to do this.”

These aren’t interchangeable. Returning 401 for an authorization failure incorrectly suggests the problem is a missing or invalid login, when the real problem is a role or permission the user simply doesn’t have.

What Authorization Looks Like in Practice

The rest of this module builds this concretely: a role field on a user (already added to the JWT payload in Module 3’s exercises), and middleware that checks it, layered on top of the authentication middleware from Modules 2 and 3, not replacing it.

Try It

  1. Explain, in your own words, the difference between “who is this?” and “is this person allowed to do this?”
  2. Look at the vulnerable route above, and describe, concretely, what a malicious logged-in user could do with it.
  3. Explain why 401 and 403 need to stay distinct, and what each one tells a legitimate client trying to handle the error correctly.

Recap

  • Authentication verifies identity, authorization checks permission, a route can correctly implement one and completely miss the other.
  • A route that checks authentication but not authorization is a real vulnerability, not just a theoretical gap.
  • 401 means “I don’t know who you are,” 403 means “I know exactly who you are, and the answer is no.”

Next lesson: adding roles to a user, and building middleware that checks one.