Authorization and Access Control (RBAC)
Deciding what an authenticated user is allowed to do
- state the difference between authentication and authorization precisely;
- model access with roles and with finer-grained permissions;
- guard Express routes with a reusable authorization middleware;
- enforce ownership so users only touch their own resources;
- choose between session/cookie and token based access, and know their trade-offs.
1. Authentication vs authorization
These two words are constantly confused because they sit next to each other in the request pipeline, but they answer different questions:
- Authentication (authN) -- who are you? The user proves their identity, typically with a password, and receives a session or a JWT. The previous topic, Authentication with JWT, is entirely about this step.
- Authorization (authZ) -- what are you allowed to do? Given a known identity, the server decides whether this request is permitted.
A useful mental model: authentication happens once per session (at login), while authorization happens on every single protected request. A valid token is a ticket that proves who holds it; it is not a backstage pass to every room. The bouncer still checks, at each door, whether your ticket grants entry there.
Analogy. Think of a hotel. The front desk authenticates you: it confirms your reservation and hands you a keycard. That card does not open every door. When you tap it on room 412, the lock authorizes you -- it checks whether this specific card is allowed through this specific door. The gym and the pool may open for everyone; the staff-only corridor stays locked. Same card, different decisions per door.
Why the split matters. Confusing the two produces a classic vulnerability: a route checks that a token is valid and stops there, assuming a valid user is an allowed user. That is broken access control -- for years the number-one item on the OWASP Top Ten. Verifying identity and checking permission are two separate gates, and both must be closed.