Whenever the conversation turns to web system design or security, two words are guaranteed to show up: "authentication" and "authorization." They look so alike on the page that people mix them up all the time. Both start with the same five letters, after all. Asking people never to confuse them is a little harsh.
Mixing up the words is merely embarrassing. The real trouble starts when a system is designed with the two blurred together. That can lead straight to serious security risks. So I decided to sort out, once more, how they differ and how they relate.
If I had to put it in a single line, authentication is confirming who a user is. Authorization, by contrast, is deciding what that user is allowed to do. Picture an office building: the first is the front desk, the second is which doors your visitor badge will open. I'll stick with that building for the rest of this post.
Authentication as the Front Desk
Authentication is the equivalent of showing your ID at the front desk. The system checks whether whoever is accessing it really is who they claim to be. Its purpose is identifying the user, nothing more and nothing less.
There are plenty of ways to do it. Logging in with an email address and password, OAuth login with a Google or GitHub account, biometric authentication with a fingerprint or face. Still, they all arrive at the same place. The whole point is establishing that "the one sending this request is User A."
Authorization as the Visitor Badge
Authorization, on the other hand, is the granting and checking of permissions. It determines whether a particular user may view, edit, or delete a particular resource. It works the same way a badge opens some doors and not others. Its purpose is access control.
Examples are not hard to find. Only administrators can press the delete-user button. Even a logged-in user cannot read someone else's private diary. Only users on a paid plan get the advanced analytics features. All of this is authorization's territory, and what comes out is a verdict: "User A may (or may not) delete this data."
Order of Operations, and the Pitfall
In a typical application, authentication first identifies the user, and authorization then checks their permissions. You confirm the identity with "You are User A, right?" and then draw the line with "User A is not an administrator, so deletion is forbidden." Sign in at the desk, then move around within what your badge allows. As orderings go, it is perfectly sensible.
The crucial point is that passing authentication does not make authorization unnecessary. Assume that a logged-in user must be safe, and skip the authorization check. Now a regular user can quietly call an administrator's API. One privilege escalation vulnerability, served fresh.
It is the equivalent of handing the master key to the vault to a visitor who merely gave their name at reception. In a real building, security would come running. An API just dutifully carries on. Nobody is going to stop it for you, so you have to write the thing that stops it yourself.
That sums up the difference between authentication and authorization. Authentication is the identity check at the front desk; authorization is the set of doors your badge may open. Getting past the desk does not mean you can walk into every room. Designing the two as separate things is the first step toward a secure application.