17 Taming authorization: RBAC, ABAC, ReBAC

Authorization is the discipline that decides not just who you are, but what you’re allowed to do across a growing sprawl of apps, APIs, and services. This chapter contrasts three core models—RBAC, ABAC, and ReBAC—showing where each excels and where it breaks down, and explains how to keep authorization maintainable as systems scale from monoliths to microservices. It emphasizes choosing the right model for context, preventing drift and complexity, and designing enforcement that’s consistent, auditable, and resilient.

RBAC grants access via roles mapped to permissions, making it fast, intuitive, and widely supported, but prone to role explosion and weak at context-specific decisions. ABAC evaluates attributes of users, resources, and environment to enforce least privilege with fine-grained, dynamic rules; its power brings policy complexity, dependency on accurate, consistent attributes, and potential performance costs. ReBAC bases decisions on explicit relationships like ownership, membership, sharing, or delegation, fitting collaborative, hierarchical, and multi-tenant domains; its challenges include modeling and querying relationship graphs at scale and explaining indirect, inherited access.

In monoliths, authorization is simpler because all context is local; modular designs let each domain module guard its own resources and enable clearer testing, auditing, and logging. In distributed systems, every service must enforce access independently—never trusting upstream checks—and teams must share precise semantics for roles and attributes. Practical patterns include combining IdP-issued tokens with consistent claims, using dedicated policy/authorization services for fine-grained ABAC or ReBAC, and treating a central relationship store as critical infrastructure. The trade-offs are real: avoid inconsistent attribute vocabularies, mitigate single points of failure, and be cautious with embedding relationships in tokens to prevent stale, incomplete, or forged access.

Comparing RBAC, ABAC, and ReBAC. RBAC grants access based on predefined roles like user, manager, or admin. ABAC adds flexibility by using user and resource attributes such as department, shift, and clearance level to make decisions. ReBAC focuses on the relationships between entities, for example, who owns a resource or who is responsible for whom, making it ideal for collaborative and delegated access scenarios.

Roles and their associated permissions in RBAC. In role-based access control, each role represents a bundle of permissions. A user assigned to a role automatically inherits all the permissions granted by that role. This structure simplifies access control but can become difficult to manage as permission needs grow more specific.

ABAC rule based on multiple user attributes. In this ABAC example, access to documents is granted if a user has a clearance level of "top" or belongs to the "US" region. Mary meets the clearance requirement, and John meets the region condition, so both are allowed access. Bob, who has neither "top" clearance nor "US" region, is denied. This highlights how ABAC evaluates access dynamically based on attribute values rather than fixed roles.

Attribute inconsistency leads to broken authorization. In this example, all users are meant to access documents if they are from Europe. However, inconsistent attribute values like "EU", "Europe", and "FR" cause authorization failures.

Enriching authorization claims across system layer. The identity provider issues a token with basic claims, such as roles or user ID. The API Gateway can enhance the token with request-specific claims, like active project IDs or request origin. Finally, backend services (like the Order Service) may fetch additional business-specific data, such as user preferences, access scope, or customer assignments, from a profile service or a custom authorization component. This layered enrichment ensures services receive the right context to make fine-grained authorization decisions.

Using a central relationship store for ReBAC in a microservices architecture. Each service syncs its relationship data (like ownerships, memberships, or associations) to a central relationship store. When a service needs to authorize a request, it queries the store to evaluate whether a valid relationship exists between the user and the resource in question.

A service querying the central relationship store to evaluate access. In a ReBAC-enabled architecture, services don’t store or compute relationship logic locally. Instead, when the Payment Service needs to verify if user “joe” owns specific invoices, it sends a query to the central relationship store. The store evaluates the relationship graph and returns the answer.

Central relationship store as a single point of failure. If the central relationship store becomes unavailable, services relying on it for authorization cannot validate user-resource relationships. This dependency introduces a potential single point of failure: even if business services are fully operational, access checks may fail, blocking critical functionality across the system. High-availability strategies or fallbacks are essential to mitigate this risk.

• RBAC assigns access based on roles, making it easy to implement and widely supported, but it can lead to role explosion in larger systems.
• ABAC adds flexibility by evaluating user, resource, and environment attributes, enabling context-aware decisions but requiring consistent attribute definitions and data quality.
• ReBAC uses relationships between entities to determine access, allowing fine-grained permissions in collaborative or multi-tenant systems but needing a relationship graph or central store.
• Monoliths simplify authorization logic, making implementing and testing all three models locally easier. Authorization model implementation is even easier and more efficient when the monoliths are designed modular.
• In distributed systems, all services must agree on what roles, attributes, and relationships mean. If they don’t, access rules become inconsistent and security gaps can appear.
• Service-oriented systems demand each service enforce its own rules, making identity propagation and consistent interpretation of roles and attributes essential.
• Cloud-native and serverless architectures offload part of the authorization logic to IAM policies, combining app-level decisions with infrastructure-enforced rules.
• In distributed environments, consistency and trust are key.
• Choosing between RBAC, ABAC, and ReBAC depends on the system’s complexity and access patterns, and in many systems, a hybrid approach provides the best balance.

FAQ