Authentication vs authorization

Published 15 October 2026

At Delhi airport you are checked twice. At the terminal door, a CISF officer looks at your ID, then at your face, then at your ticket: are you the person this ticket was booked for? That is authentication. An hour later at gate 42, the airline scans your boarding pass: is this person on this flight, and in which seat? That is authorization. The officer at the door does not care which flight you are on. The gate agent does not check your face again. Two different questions, asked by two different people, in a fixed order.

Every API you build asks the same two questions. Most security bugs in APIs come from asking only one of them, or from asking them in the wrong place.

Two questions, always in this order#

Authentication (authn) answers "who are you?". The input is a credential: a password, an OTP, a passkey, a signed token. The output is an identity, something like { id: "ravi", org: "acme", role: "editor" }. Nothing more. Authentication does not know what Ravi is trying to do.

Authorization (authz) answers "may this identity do this action to this thing?". The input is the identity from step one, plus the action (edit), plus the resource (invoice 4471). The output is yes or no.

The order is not a convention. Authorization needs an identity to reason about, so if the first question fails, the second one cannot even be asked. Try it below. Pick a caller and an action, and watch where the request stops.

Spend a minute on three cases. The edited token: decoding a JWT is easy, anyone can read it, but changing it breaks the signature, so it fails at gate one. Asha deleting: gate one is perfectly happy, she is exactly who she says she is, and that is why gate two exists. Meera from Globex: an admin, signed in properly, and still stopped, because being an admin somewhere is not the same as being an admin here.

401 or 403: the status codes have a naming bug#

HTTP has one status code for each gate, and the first one is misnamed.

• 401 Unauthorized means gate one failed. The credentials are missing, expired or invalid. RFC 9110 describes it as lacking "valid authentication credentials". It should have been called Unauthenticated. The client's correct reaction is to refresh the token or send the user back to the login page.
• 403 Forbidden means gate two failed. The server knows who you are, and the answer is no. Logging in again will not help, so the client should stop retrying and show a message.

Mixing them up has real consequences. Return 403 for an expired token and a well written client gives up instead of refreshing, and your users get logged out for no reason. Return 401 for a permission problem and the client loops: refresh, retry, 401, refresh.

There is a third answer worth knowing. When the resource belongs to someone else entirely, many APIs return 404 instead of 403, so a stranger cannot even confirm the thing exists. Ask GitHub for a private repository you cannot see and you get a 404, not a 403.

How the two gates look in a real system#

Notice where each gate lives. Authentication happens once, at the edge. You prove who you are to an identity provider with a password and an OTP, it hands you a signed token, and from then on every service only has to check the signature, which takes microseconds and needs no database call.

Authorization happens on every request, next to the data. The gateway can do coarse checks ("does this token have the invoices:write scope at all?"), but only the invoice service knows that invoice 4471 belongs to Acme. That fact lives in its database. A check that needs the resource has to run where the resource is.

The bug behind most API data leaks#

Go back to the question at the top. A logged in user changes /orders/1001 to /orders/1002 and sees a stranger's order. Authentication worked perfectly. The server knew exactly who was asking. It just never asked whether that person was allowed to see order 1002.

This has a name, broken object level authorization (BOLA, also called IDOR), and it has been number one on the OWASP API Security Top 10 in both the 2019 and 2023 editions. It is common because the buggy code looks completely normal:

// Logged in: yes. Allowed to see this invoice: never asked.
app.get('/invoices/:id', requireLogin, async (req, res) => {
  const invoice = await db.invoice.findUnique({ where: { id: req.params.id } })
  if (!invoice) return res.sendStatus(404)
  res.json(invoice)
})

The middleware name gives the game away. requireLogin on a route feels like security, and it is, for gate one. Gate two has no middleware that can do it for you, because only the handler knows which invoice was asked for.

Ways to make the authorization decision#

Once you know who someone is, there are three common ways to decide what they may do. Most real systems start with the first and add the others where it stops fitting.

For any of the three, you can write the rules as plain if statements in your code, or move them into a policy engine such as Open Policy Agent (OPA) or AWS's Cedar, where rules live in their own files, get reviewed like code and can be tested on their own. Start with if statements in one well named function (can(user, action, resource)), and move to an engine when several services need the same rules.

Checkpoint#