LESSON 29.2
Authorization with RBAC, ABAC and relationship models
Deciding what authenticated users can do across services. Role-Based Access Control, Attribute-Based Access Control, Policy Decision Points, and Google Zanzibar ReBAC graphs.
5 min read
Once an application verifies who a user is via authentication, it must determine what that user is permitted to do. This is authorization.
Simple applications hardcode authorization checks (if user.is_admin), but as microservices proliferate and permission logic evolves, access control must be decoupled into dedicated authorization engines.
RBAC vs ABAC
Role-Based Access Control (RBAC)
- Simple to understand and audit
- Fast evaluation (check if user has role X)
- Easy to assign in enterprise directory groups
- Role explosion (creating 'BillingViewer', 'BillingEditorUS', 'BillingEditorEU')
- Cannot express contextual rules (e.g. only between 9 AM and 5 PM)
Pick it when: Standard internal enterprise dashboards, coarse admin privileges.
Attribute-Based Access Control (ABAC)
- Highly expressive policy rules
- Evaluates contextual environment variables (IP, time, device health)
- Supports fine-grained row-level filters
- Higher evaluation latency and CPU usage
- Complex debugging when overlapping policies conflict
Pick it when: Healthcare, compliance, multi-tenant B2B apps with complex sharing rules.
Architecture: Policy Enforcement and Policy Decision
Modern distributed architectures decouple policy evaluation using the PEP / PDP pattern:
- Policy Enforcement Point (PEP): Located at the API gateway or service middleware. Intercepts incoming requests, extracts subject identity and resource targets, and queries the PDP.
- Policy Decision Point (PDP): An isolated decision engine (such as Open Policy Agent or AWS Cedar). Evaluates declarative policies against input attributes and returns a boolean decision (
allow: true). - Local sidecar evaluation: To avoid introducing a network hop to every API request, PDP engines run as local in-process libraries or localhost sidecars, evaluating rules in under 1 millisecond.
Relationship-Based Access Control: Google Zanzibar
Modern collaborative platforms (Google Docs, Figma, GitHub, Notion) cannot be modeled cleanly with simple RBAC. Permissions are inherited dynamically through hierarchies:
- "Alice can view Document A because Alice is a member of Team Engineering, which owns Folder Projects, which contains Document A."
This is Relationship-Based Access Control (ReBAC), pioneered by Google's Zanzibar paper.
- Tuple store: All permissions are stored as discrete relation tuples:
document:report_2026#viewer@group:engineering#member - Graph expansion: Checking whether user Bob can read Document A translates into traversing a directed graph from user Bob to Document A.
- Zookie tokens: Zanzibar issues consistency tokens ("Zookies") to ensure authorization checks reflect causal ordering and prevent "new enemy" authorization leaks after permission revocations.
Try it
Relationship-based Authorization Service HLD
Design a distributed relationship-based authorization system that evaluates deep permission inheritance graphs at scale.