17 Taming authorization: RBAC, ABAC, ReBAC

 

This chapter covers

  • Comparing RBAC, ABAC, and ReBAC to get how each model handles access control
  • Identifying when a system needs more than just roles to make access decisions
  • Designing authorization layers that scale without turning into a maintenance nightmare
“So… you've locked the front door.
Great! But now comes the real question:
who gets to open the fridge?”

Welcome to the wild world of authorization, the part of security that decides not just who you are, but what you're allowed to do. Most systems today aren’t just one app or one database. They’re a sprawling jungle of services, APIs, functions, dashboards, admin panels, and probably three forgotten Lambda functions you deployed last year and now can’t find. And each of these needs to decide:

“Should I allow this request?”
“Can this user see this document?”
“Should I trust this service call?”

Authorization models are how we answer those questions. In this chapter, we’ll walk through authorization models with real-world examples, explain where they shine (and break), and look at how authorization plays out in monoliths, microservices, and clouds. You’ll learn how companies actually enforce “who can do what,” and what tools and patterns help keep that logic sane.

17.1 What are core authorization models

Before we start throwing around tokens, graphs, and policy engines, let’s take a step back and ask a simple question: How do systems actually decide who’s allowed to do what?

17.1.1 Role-Based Access Control (RBAC)

17.1.2 Attribute-Based Access Control (ABAC)

17.1.3 Relationship-Based Access Control (ReBAC)

17.1.4 Exercises

17.2 Authorization in real-world architectures

17.2.1 Authorization within monoliths

17.2.2 Service-oriented authorization

17.2.3 Exercises

17.3 Answers to questions

17.4 Summary