Stop 04 · Core Security ConceptsTopics · 1/10

Authentication vs Authorization

Part of the Cybersecurity Roadmap

In short

"Who are you?" and "What are you allowed to do?" sound similar, but mixing them up causes some of the most common security bugs in real apps. Keep them separate in your head from today.

Authentication verifies who you are (login), authorization determines what you're allowed to do once verified — a huge share of real vulnerabilities come from confusing or mishandling this distinction.

The blob shows an invitation to a guard at a wedding hall while a kitchen door is roped off.

Think of it like this

Entry at a wedding hall

The guard checks your invitation at the door: you're a real guest (authentication). But being a guest doesn't let you walk into the kitchen or the bride's room. Those need a separate permission (authorisation). Passing the first check never means passing the second.

Watch it happen

Two separate checks on every request

Riya
App
Auth check
Permission

login + OTP

1/6Riya logs in with her password and an OTP.

The big ideas

What you need to know

Authentication = identity

Proved with something you know (password), have (phone, key) or are (fingerprint). MFA combines two or more.

Authorisation = permission

Decided after login, using roles, ownership or rules. It must run on every request.

Always on the server

Hiding a button in the UI is not authorisation. Anyone can call the API directly.

401 vs 403

401 Unauthorized really means 'not authenticated'. 403 Forbidden means 'authenticated, but not allowed'.

See it in code

Walk through the code

ts
1// Express: one middleware per question2function requireLogin(req, res, next) {3  if (!req.user) return res.status(401).json({ error: "Log in first" });4  next();5}6 7function requireRole(role: string) {8  return (req, res, next) => {9    if (req.user.role !== role) return res.status(403).json({ error: "Not allowed" });10    next();11  };12}13 14app.delete("/users/:id", requireLogin, requireRole("admin"), deleteUser);

1/3Authentication: no user on the request means nobody logged in, so 401.

Keeping the two checks as separate middleware makes it obvious when a route has one but not the other.

Save yourself the pain

Common mistakes

Oops

Assuming that anyone who is logged in can access any record.

Do this instead

Check ownership or role on each request. 'Logged in' only answers who, never what.

Oops

Doing the role check only in the frontend.

Do this instead

Enforce it on the server. The frontend check is just a nicer experience, not security.

Your mission

Find the missing check

~25 min

Quick check

A logged-in student opens /admin/reports and sees all staff salaries. What failed?

Go deeper

  1. 1Give a concrete example of a system where authentication succeeded but authorization should have failed.
  2. 2Learn why 'broken access control' (OWASP Top 10, Phase 5) is fundamentally an authorization failure.
  3. 3Practice explaining this distinction to someone with no security background.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge