Who you are, what you may do

Think of it when a request reads or changes data, and you must know who sent it and whether they are allowed.

In everyday life

At a hotel, the front desk checks your passport: who you are. Your key card then opens only your own room: what you may do. A guest with a valid passport still cannot open room 1042.

One case

A shop’s order page loads from the address /orders/1041. The server checks that the visitor is logged in, then returns order 1041. A logged-in customer changes the number to 1042, then tries up to 1046, and sees 5 strangers’ names and addresses. The login check worked. The check that the order is theirs did not exist.

Every request passed the login check
The case, cell by cell1 cell = 1 order number
This customer may see it
yesnonononono
The server showed it
yesyesyesyesyesyes
Strangers' orders shown
5
Login checks passed
6
The server asked “who are you?” and never asked “is this yours?”.

Every case

Authentication and authorization answer different questions, and a system needs both on every request. Knowing who someone is says nothing about what they may touch. The common mistake is to check the login once, then trust any record number the request asks for. The server must check each request against the exact data it reads, because the client can send anything.

The word

Engineers call this

authentication, authorizationTwo separate checks. Authentication asks “who are you?”, for example with a password. Authorization asks “what may you do?”, for example see only your own orders.

On every request, check who is asking, then check that they may touch this exact record. Give each person and each program only the access its job needs.

Where this idea leads