Authorisation
In identity and access, authorisation is deciding what an already-authenticated identity is allowed to do. It runs after authentication has established who the caller is, and it is a per-request question rather than a per-session one, because the answer depends on the specific object and operation being requested.
What it is
Authorisation is the part of access control that determines what permissions and what rights a user, a program or a system has over a digital resource. It answers the question of what you may do, and it always comes after authentication.
It rests on rules and policies defined in advance, which set what may be read, written, executed or modified according to the function and responsibilities of each person. The usual mechanisms are access control lists (ACL) and role-based access control (RBAC), where permissions are grouped into roles and roles are assigned to people.
Its purpose is to sustain the confidentiality, integrity and availability of information: only those with the necessary authority may interact with a given asset.
How it works
Authentication and authorisation answer different questions and fail in different ways. Authentication asks who you are and happens once per session. Authorisation asks whether you may do this particular thing to this particular object, and has to happen on every request, because a valid session is not a permission.
Two dimensions matter in practice. Vertical authorisation controls what class of function you may invoke: whether you may reach an administrative operation at all. Horizontal authorisation controls which instances of an object you may touch among the many your role permits in general. The second is harder, more commonly broken, and less visible, because everything about the request looks normal.
What goes wrong
The failure is nearly always a check in the wrong layer or a check that trusts client-supplied context. Deriving the tenant from a field in the request instead of from the session hands the decision to the caller. Filtering a list view correctly while the detail handler trusts that the identifier could only have come from the list is the same mistake with an extra step, and it is exactly what BOLA and IDOR describe.
The second pattern is inconsistency across entry points. The same object is reachable through a web route, an API version, a mobile endpoint, a bulk export and a background job, and the check exists on some of them. Centralising the decision fixes this; re-implementing it per handler guarantees the drift.
The third is confusing the standards. OAuth is a delegation framework: it decides what a client application may request on a user’s behalf, and it says nothing about whether this user may see this record. Presenting a valid token as proof of authorisation is a category error we find in production APIs regularly.
Where this shows up in an audit
We ask for at least two accounts in each role, because horizontal authorisation cannot be proved with one. The finding states the identity used, the object requested, the operation, the response, and the layer where the decision should have been made. The comparison table between authentication and authorisation, with the failure modes of each, lives on the authentication entry so it stays in one place. This is part of how object and function level checks are tested in an API.