Authentication and authorization are two distinct security concepts that are often confused. Getting them mixed up is a common source of security vulnerabilities.
The One-Sentence Definitions
- Authentication (AuthN) — "Who are you?" — verifying identity
- Authorization (AuthZ) — "What can you do?" — verifying permission
A Real-World Analogy
At an office building:
- Authentication — showing your ID badge to the security guard. Proves you are who you say you are.
- Authorization — your badge grants access to floors 1-3, but not the server room on floor 5. You're verified (authenticated), but restricted (authorized for limited access).
In Web Applications
// Authentication: verify the user's identity
POST /auth/login
{ "email": "[email protected]", "password": "secret" }
→ Validates credentials → Issues a JWT token
// Authorization: check what the authenticated user can do
GET /api/admin/users
Authorization: Bearer eyJhbGc...
→ Token is valid (authenticated ✅)
→ User has role "admin"? No (authorized ❌) → 403 ForbiddenCommon Mistakes
- Checking authentication but not authorization — verifying the token is valid, but not checking if the user is allowed to access THAT specific resource. An authenticated user can read other users' data.
- Authorization only in the UI — hiding an "admin" button from non-admin users but not checking permissions on the API endpoint. The API is accessible directly.
- Trusting the user's claimed role — if the JWT payload contains
"role": "admin", don't trust it without verifying the signature. Never let users set their own role.
The Sequence
Authentication always comes before authorization. You can't determine what someone is allowed to do if you don't know who they are. A 401 Unauthorized means "not authenticated." A 403 Forbidden means "authenticated but not authorized."
Request arrives → Authentication (who are you?) → Failed → 401 Unauthorized
→ Passed
↓
Authorization (what can you do?) → Denied → 403 Forbidden
→ Granted → Process request → 200 OK