I can't tell you how many times I've seen these two words used interchangeably.
Even experienced developers sometimes slip up:
"We need to add Google Auth so users can authorize with their email."
No. That's authentication.
"The JWT token authenticates whether the user is an admin."
No. That's authorization.
They sound similar. They work together. But they are not the same thing.
And mixing them up leads to security holes, confused code, and embarrassing bugs.
Here's the one analogy that makes it stick forever.
The Bouncer Analogy πͺ
Imagine you're at a nightclub.
Step 1: Authentication (Getting past the front door)
You walk up to the bouncer. He asks:
"Do you have an ID?"
You show your driver's license. He checks the photo. He scans it. He confirms:
"Okay, you are who you say you are. You're on the guest list. Come in."
That's authentication. You proved your identity. You're in the club.
Authentication answers: "Are you who you claim to be?"
Step 2: Authorization (Getting into VIP)
Now you're inside the club. You see the VIP section β better drinks, better view, actual seats that aren't sticky.
You try to walk in. Another bouncer stops you:
"Whoa there. This is VIP. Do you have a wristband?"
You show your black wristband (which you paid $500 for). He checks it and says:
"Cool. You're authorized. Go ahead."
That's authorization. Your identity is already confirmed. Now we're checking what you're allowed to do.
Authorization answers: "Are you allowed to do this specific thing?"
The Table That Finally Makes It Click
Authentication Authorization
Question it answers "Who are you?" "What can you do?"
When it happens First (at login) After (on each request)
What it proves Identity Permissions
How it works Passwords, biometrics, security keys Roles, permissions, policies
Tells you "You are Bob" "Bob can delete posts"
Bouncer analogy Checking your ID at the door Checking your VIP wristband
HTTP Status Code 401 Unauthorized (ironically named) 403 Forbidden
Side note: Yes, HTTP 401 says "Unauthorized" but actually means "unauthenticated." It's a historical mistake that confuses everyone. Just remember: 401 = Login first. 403 = You're logged in but not allowed.
Real Web Examples
Example 1: Logging into Gmail
- Authentication: You type your email + password. Google checks it's really you. (Success β you get a session cookie or JWT token)
- Authorization: You try to delete an email. Google checks: "Does this user have 'delete' permission for this email?" (Yes, it's your own email)
Same user, same login, but authorization happens on every single action.
Example 2: Google Drive sharing
Β· Authentication: You log into your Google account.
Β· Authorization: You try to open a shared document. Google checks: "Is this user on the 'can view' list?" If yes β authorized. If no β 403 error.
You are authenticated (Google knows it's you), but not authorized (you don't own that doc).
Example 3: Admin dashboard
// Authentication: Did the user log in?
if (!req.user) {
return res.status(401).json({ error: "Please log in first" });
}
// Authorization: Is the logged-in user an admin?
if (req.user.role !== "admin") {
return res.status(403).json({ error: "Admins only" });
}
// If we reach here, user is BOTH authenticated AND authorized
res.send("Welcome to the admin panel");
See the difference? Two checks, two different purposes.
The Technologies (What actually powers authN and authZ)
Now let's connect the theory to the actual code you'll write.
Authentication Technologies (Proving who you are)
Technology What it does When to use
Passwords + Hash (bcrypt) User provides secret; you compare hashed version Most apps (standard)
JWT (JSON Web Token) Encoded token containing user ID + signature Stateless APIs, mobile apps
Sessions (with cookies) Server stores user data; cookie acts as key Traditional web apps (Rails, PHP, Node with express-session)
OAuth 2.0 "Login with Google/GitHub/Facebook" Letting third parties prove identity
Biometrics Fingerprint, FaceID, passkeys Mobile apps, high-security
2FA / MFA Password + one-time code from phone Any app with sensitive data
Authentication result: You get a credential (session cookie, JWT token, API key) that you send with every subsequent request.
Authorization Technologies (What you're allowed to do)
Technology What it does When to use
RBAC (Role-Based Access Control) Users have roles (admin, editor, viewer); roles have permissions Most business apps (simplest)
ABAC (Attribute-Based Access Control) Permissions based on attributes (time of day, user location, resource owner) Complex systems (healthcare, finance)
ACL (Access Control Lists) Each resource has a list of who can access it File systems, legacy apps
Policies (Casbin, OPA) Declarative rules: "user can edit post if user.id == post.authorId" Fine-grained permissions
Authorization result: A yes/no answer for each action. No tokens. Just logic.
The Confusion: JWT, Sessions, Cookies, localStorage
This is where beginners get lost. Let me untangle it.
What stores your authentication state?
After you log in, you need to remember that you're authenticated for future requests.
Option 1: Sessions (Server-side)
1. You log in.
2. Server creates a session record in its database (or Redis).
3. Server sends you a cookie containing a session ID.
4. You send that cookie with every request.
5. Server looks up the session ID to know who you are.
Option 2: JWT (Client-side)
1. You log in.
2. Server creates a JWT token (contains your user ID, expiration, signature).
3. Server sends you the token.
4. You store it in localStorage or an HTTP-only cookie.
5. You send the token in the Authorization header with every request.
6. Server verifies the signature (no database lookup needed).
Which one should you use?
Sessions JWT
Where is data stored? Server (database/Redis) Client (token itself)
Can you revoke instantly? β
Yes (delete session from DB) β No (token valid until expiration)
Scales how? Need shared session store (Redis) Stateless (any server can verify)
Best for... Traditional web apps Mobile apps, microservices, SPAs
My advice for beginners: Start with sessions + HTTP-only cookies. It's simpler and more secure by default. Move to JWT only when you have a reason (e.g., mobile app, separate API server).
localStorage vs. cookies (Security warning!)
This is critical.
Storage method Accessible by JavaScript? Vulnerable to XSS? HttpOnly option?
localStorage β
Yes (any script can read it) β Yes (high risk) β No
Regular cookie β
Yes β Yes β No
HttpOnly cookie β No (JS cannot read it) β
No (much safer) β
Yes
Rule of thumb:
Β· Never store authentication tokens in localStorage if you care about security. Any XSS vulnerability = attacker steals every user's token.
Β· Use HttpOnly cookies for sessions or JWTs. They can't be read by JavaScript.
// BAD (vulnerable to XSS)
localStorage.setItem("token", userJWT);
// GOOD (more secure)
// Set cookie on server with:
Set-Cookie: token=xyz; HttpOnly; Secure; SameSite=Strict
OAuth 2.0 β The special case
OAuth is often called "authentication," but that's not quite right.
OAuth is actually authorization that implies authentication.
Here's how it works:
- You click "Login with Google."
- Google asks: "This app wants to see your email and name. Allow?"
- You say yes.
- Google tells your app: "This user is bob@gmail.com" (authentication info) AND "Here's a token to access their Google Drive" (authorization).
OAuth solves: "Let me prove who I am without giving you my password, and also let me give you limited access to my data."
Common confusion: People call OAuth "social login" (authentication), but OAuth was designed for delegated authorization (like "let this app post to my Twitter"). The login part is a bonus.
Common Real-World Scenarios
Scenario 1: You're logged into Netflix but can't watch a specific movie
Β· Authentication: β
You logged in. Netflix knows it's you.
Β· Authorization: β Your plan doesn't include that movie (or it's region-locked).
Error message: "This title is not available in your region." (403 Forbidden)
Scenario 2: You try to delete a comment on Reddit that isn't yours
Β· Authentication: β
You're logged in.
Β· Authorization: β You didn't write that comment.
Error message: "You cannot delete this comment." (403)
Scenario 3: You open a private GitHub repo without logging in
Β· Authentication: β GitHub has no idea who you are.
Β· Authorization: βΈοΈ Not even checked because you're not authenticated.
Error message: "Not Found" (404 β GitHub does this on purpose to hide private repos exist). But technically it's a 401.
The 5-Minute Implementation (Node.js + Express)
Here's a minimal example showing both concepts:
const express = require('express');
const app = express();
// Fake database
const users = [
{ id: 1, email: 'alice@example.com', password: 'alice123', role: 'admin' },
{ id: 2, email: 'bob@example.com', password: 'bob123', role: 'viewer' }
];
const posts = [
{ id: 1, title: 'Post 1', authorId: 1 },
{ id: 2, title: 'Post 2', authorId: 2 }
];
// ---------- AUTHENTICATION ----------
// Login endpoint β proves who you are
app.post('/login', (req, res) => {
const { email, password } = req.body;
const user = users.find(u => u.email === email && u.password === password);
if (!user) {
return res.status(401).json({ error: 'Invalid credentials' }); // 401 = unauthenticated
}
// Create a session (in real life, use express-session)
req.session.userId = user.id;
res.json({ message: 'Logged in!' });
});
// Check authentication middleware
function isAuthenticated(req, res, next) {
if (!req.session.userId) {
return res.status(401).json({ error: 'Please log in first' });
}
next();
}
// ---------- AUTHORIZATION ----------
// Check authorization middleware (role-based)
function isAdmin(req, res, next) {
const user = users.find(u => u.id === req.session.userId);
if (user.role !== 'admin') {
return res.status(403).json({ error: 'Admins only' }); // 403 = forbidden
}
next();
}
// Check authorization (ownership)
function isOwner(req, res, next) {
const postId = parseInt(req.params.id);
const post = posts.find(p => p.id === postId);
const user = users.find(u => u.id === req.session.userId);
if (post.authorId !== user.id && user.role !== 'admin') {
return res.status(403).json({ error: 'You can only edit your own posts' });
}
next();
}
// ---------- ROUTES ----------
// Anyone can view (no authentication needed)
app.get('/posts', (req, res) => {
res.json(posts);
});
// Authenticated only (any logged-in user)
app.post('/posts', isAuthenticated, (req, res) => {
// Create a new post
res.json({ message: 'Post created' });
});
// Authorization: must be admin OR owner
app.put('/posts/:id', isAuthenticated, isOwner, (req, res) => {
res.json({ message: 'Post updated' });
});
// Authorization: admin only
app.delete('/posts/:id', isAuthenticated, isAdmin, (req, res) => {
res.json({ message: 'Post deleted' });
});
See the pattern?
- Authentication happens first (isAuthenticated).
- Authorization happens second (isAdmin, isOwner).
- You can be authenticated but not authorized (403).
- You can be neither (401).
The Security Checklist
When building auth, use this mental checklist:
Question Check
Are passwords hashed with bcrypt (not plain text)? β
Is HTTPS enabled everywhere? β
Are session cookies marked HttpOnly + Secure? β
Do you have rate limiting on login attempts? β
Does every protected endpoint check authentication FIRST? β
Does every sensitive endpoint check authorization SECOND? β
Are you using the correct HTTP status codes (401 vs 403)? β
Are JWT tokens (if used) stored in HttpOnly cookies, not localStorage? β
Quick Reference Card (Save This)
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β AUTHENTICATION AUTHORIZATION β
β "Who are you?" "What can you do?" β
β β
β First (login) After (every action) β
β Passwords, JWT, OAuth Roles, permissions β
β HTTP 401 (Unauthorized) HTTP 403 (Forbidden) β
β β
β Bouncer at the door πͺ Bouncer at VIP ποΈ β
β "Show ID" "Show wristband" β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Your Turn
Go check your own code (or a project you're working on):
- Do you have endpoints that check authentication?
- Do you have separate checks for authorization?
- Are you using 401 vs 403 correctly?
- Are your tokens in localStorage? (Move them if yes!)
Leave a comment with your biggest "aha moment" or your worst auth-related bug story.
Follow for more security deep dives (next up: JWT vs. Sessions β which one actually wins?)
TL;DR: Authentication = proving you're you (login). Authorization = proving you're allowed to do the thing (permissions). One happens first, one happens on every request. Mix them up and hackers win.
Top comments (0)