Identity & Access · Chapter 1 of 16
Authentication, authorisation, audit
Three different questions. Conflating them is the root of most identity incidents.
Identity work has an unusually bad acronym problem, and it hides a simple structure. Almost everything in this field is one of three questions, and the discipline gets much easier once you can place any control into the right one.
Why the distinction pays off immediately
When an incident happens, the first useful question is which of the three failed. Almost every reported “account compromise” is really two failures: authentication let someone in, and authorisation let them reach far more than that account should have touched. The second failure is what turned an incident into a breach, and it is nearly always the cheaper one to have prevented.
- Authentication is largely a solved problem if you deploy phishing-resistant factors. Passkeys and FIDO2 hardware keys defeat the credential phishing that causes most intrusions, because the credential is bound to the origin and cannot be replayed elsewhere.
- Authorisation is where the hard, unglamorous work is — and where most organisations are weakest, because it requires knowing what every person should be able to reach, which nobody has ever fully written down.
- Audit is what makes the other two provable. Without it you have opinions about your access posture rather than evidence.
The question that reframes an identity programme
Not “how do we stop attackers logging in?” but “when an attacker does log in as an ordinary employee, what can they reach?”
The first question has diminishing returns and a well-understood answer. The second is where the actual risk lives, and it is a question about authorisation, not authentication.
Why the three are separated, and what breaks when they are not
Authentication asks who are you. Authorisation asks what may you do. Audit asks what did you do. They are separated because they fail independently and are operated by different people — and almost every serious identity incident is a case of one being used to do another's job.
| Confusion | What it looks like in production | What it costs |
|---|---|---|
| Authentication used as authorisation | "They're logged in, so they can see it" | Every authenticated user reaches every resource. This is the single most common serious access bug in internal tools |
| Authorisation checked in the UI only | The button is hidden for users who lack permission | The API is open. Hiding a control is not a control — it is a hint |
| Audit that records the service account | Every log line says svc-reporting | You cannot answer 'who did this', which is the only question anyone asks after an incident |
| Authorisation at the gateway only | Anything inside the perimeter is trusted | One compromised internal service reaches everything. The 2025 advisory that let a spoofed header bypass a framework's middleware is exactly this shape |
The audit row is the one people underestimate. A log that records which service acted, rather than on whose behalf, is technically accurate and operationally useless. Carrying the original principal through every hop — and being able to say ‘user X, acting through service Y, at time T’ — is the difference between an audit trail and a collection of events.
The question that reveals a system's real access model
“Show me how the system decides that this specific person may see this specific record.”
You are listening for where the decision happens and how many places can make it. Three answers, in descending order of health:
One place, close to the data — a policy layer or a database rule every read passes through. Hard to bypass, easy to audit, and the only design where a new caller is safe by default.
In each service, consistently — workable, and every new service is a new chance to get it wrong.
At the edge, and then trusted inward — convenient, and one internal compromise reaches everything.
And the follow-up that finds the real answer: “what happens if I call the API directly instead of going through the interface?” The hesitation before the answer is the finding.
Check yourself