Backend
Authorization
Deciding what an authenticated principal may do — enforced with roles (RBAC), attributes (ABAC) or policies. It runs on every protected request, ideally at one audited boundary rather than scattered across the code. The classic failure is broken access control (OWASP number one): trusting a client-supplied ID instead of verifying ownership server-side.
Purpose
Authorization decides what an authenticated caller may do — which resources and actions are permitted. It runs after authentication on every protected request and is the control that actually protects data.
When to Use It
Any multi-user system needs it: role-based access (RBAC) for most apps, attribute- or policy-based (ABAC) when rules depend on data such as owner, tenant or status. A central policy engine suits large systems.
The recurring real-world need is object-level checks — confirming this user owns this record, not merely that they hold a role.
Trade-offs
Scattering checks across controllers is easy to get wrong; centralising them is easier to audit but can become a bottleneck or an over-general rules engine. Broken access control is the OWASP #1 risk precisely because these checks are so easy to forget.
Implementation
Enforce at one audited boundary — middleware that verifies the token and the caller's role, plus an explicit ownership check against the resource. Deny by default, never trust a client-supplied ID or hidden field, and log denials. Keep the policy in code you can test rather than sprinkled ad-hoc.