Authorization
also called AuthZ
Deciding whether an authenticated principal may perform a specific action on a specific resource.
The three models, in increasing order of expressiveness and cost. RBAC assigns permissions to roles and roles to users — simple, auditable, and it degrades into role explosion when rules depend on context. ABAC evaluates attributes of the subject, resource, action and environment — expressive enough for "a manager may approve expenses in their own department under 5,000" without inventing a role per case. ReBAC answers relationship questions — "is this user a member of a team that owns the parent folder?" — which is what document and repository systems need.
The architectural failure to avoid is scattering the decision. Authorisation logic spread across controllers cannot be audited or changed coherently. Centralise the decision (a policy engine, a shared library, a mesh policy) while keeping enforcement at every resource.
And the recurring bug class: authorising the action but not the object. Checking that a user may
call GET /orders/{id} while never checking that the order belongs to them is broken object-level
authorisation, consistently the most common serious API vulnerability found in the wild.