Authorization Models: RBAC, ABAC, and Resource-Level Authorization

Permission rules often need to describe more than a person's job title. A bookstore might let support agents read customer reading lists, for example. Checking for a support_reader role makes the endpoint easy to implement, but that check alone would expose every customer's private lists to every support agent. The intended rule is narrower: an agent may read lists only for a customer their current assignment covers.

Authorization models help express these rules consistently.

This chapter explains role-based and attribute-based access control, resource-level checks, and how to combine them into enforceable API policies. It also covers collections, writable fields, changing permissions, and the consequences of a failed policy lookup.

The examples use a fictional bookstore API over HTTPS. Customers may read and rename their own private lists. Support agents may read lists during an active customer assignment and cannot rename them. Authentication has already established a trusted principal. Role names, policy rules, and response conventions are application choices.