authentication vs authorization: what is the actual difference
authentication definition, authorization definition, identity vs permission, real-world analogies, common misconceptions, HTTP context
Authentication vs Authorization
These two words get conflated constantly. They are not the same thing.
Authentication answers: Who are you? It verifies identity. When you submit a username and password, the server checks if those credentials match a known user. That is authentication.
Authorization answers: What are you allowed to do? After you are identified, the server checks whether you have permission to access a resource. An authenticated user can still be unauthorized for certain routes.
Example: A regular user logs in (authenticated). They try to access /admin. The server rejects them (not authorized). Same person, different check.
In HTTP APIs, authentication typically happens first — usually via a token or session — and authorization runs after, often using roles or scopes attached to that identity.
A practical mental model: authentication is the bouncer checking your ID at the door. Authorization is the VIP list that decides which rooms you can enter once inside.
Getting this distinction right matters for system design. Mixing them up leads to poorly scoped middleware, confusing error codes (401 vs 403), and security gaps. 401 Unauthorized actually means unauthenticated. 403 Forbidden means authenticated but not authorized. Yes, HTTP naming is inconsistent — knowing that prevents bugs.