Authentication vs authorization.
Proving who you are at the door, versus what that identity is actually allowed to do inside.
These two are often lumped together as "auth", but they answer different questions. Authentication (authn) asks "who are you?" — it is the act of proving your identity, like showing ID at the door of a building.
Authorization (authz) asks "what are you allowed to do?" — once we know who you are, it decides which rooms you may enter. Your ID badge might get you into the building (authenticated) but the door to the server room stays locked unless your role grants it (not authorized).
- Name? ID, please.1
Authentication asks one thing: who are you? Prove it.
- Checks out. You’re Alice.2
You show ID — password, passkey, token. The door now knows you’re really Alice.
- 3
That badge gets you into the building. But it doesn’t say what you may touch.
- Alice the viewer, says your role.4
Authorization asks the second question: now that we know you, what are you allowed to do?
- Read: yes. Delete: no.5
The server-room door stays locked — Alice’s role grants reading, not deleting.
- Knowing who ≠ letting them in.6
Skip that second check and a real user overreaches — the classic broken-access-control hole.
Order matters, and so does keeping them separate
Authentication always comes first — you cannot decide what someone may do until you know who they are. Conflating the two is a classic source of bugs: a system that authenticates a user but then forgets to check whether that specific user is allowed to touch this specific record creates exactly the "broken access control" holes that top security risk lists. Authentication is necessary but never sufficient.
How authorization is expressed
Once identity is established, permissions are usually modelled as roles or rules. Role-based access control (RBAC) groups permissions into roles like "admin" or "viewer" and assigns users to them. Finer-grained schemes consider attributes — the resource's owner, the time, the user's department — to decide each request. Standards like OpenID Connect handle the authentication and identity side and hand the application verified claims, which the app then uses to make its own authorization decisions.