Module 3 of 5
Authorization
Authentication says who is calling; authorization decides what they may do to this object, in this tenant, right now. This module covers object-level checks, access-control models, tenant isolation, and centralized policy.
Most API breaches do not involve breaking authentication. The attacker logs in as themselves, quite legitimately, and then asks for something that belongs to someone else. The server checks that the caller is somebody and never asks whether this caller may touch this record. Authorization is the decision that runs on every request, for every object, and it is the one most often missing.
The four lessons move outward from a single handler. They start with the object-level check and the negative tests that prove it exists, compare the models used to express permissions (roles, attributes, relationships), extend the boundary to whole tenants sharing one system, and end with moving the decision into a policy engine that can be reviewed, tested, and logged. By the end you should be able to look at an endpoint and say which check stops a second, ordinary user from reaching the first user’s data, and where that check is tested.
Lessons
- 3.aBroken object level authorizationWhy does changing an ID in a request so often return someone else's data, and how do you prove it cannot?19 min
- 3.bRBAC, ABAC and relationshipsShould permissions be expressed as roles, as attributes, or as relationships between users and objects?17 min
- 3.cTenant isolationHow do you keep one customer from ever seeing another customer's data in a shared system?19 min
- 3.dCentralizing policyWhy move authorization decisions out of application code, and what does it cost?20 min