Authorization Models (RBAC, ABAC, ReBAC)
RBAC, ABAC, and ReBAC are complementary ways to decide who may do what, based on roles, attributes, or relationships between subjects and resources.
Definition
Authorization models are formal rules that map an authenticated subject, a resource, and an action to an allow or deny decision, using roles, attributes, or relationship graphs as the basis for policy.
Context and scope
Choose a model when designing permissions for an application, and expect to combine them: roles for job function, attributes for context, and relationships for per-object sharing.
Common misconceptions
- RBAC can express per-document sharing without role explosion
- ABAC means writing arbitrary code in policy; mature engines use declarative languages
- One model must serve every resource; mixing models per resource is normal
Anti-patterns
- Encoding tenant and object IDs into role names, creating thousands of roles
- Evaluating authorization only in the UI while APIs trust client-supplied roles
- Building a relationship graph without deciding how stale it may be
Related concepts
Related examples
Authoritative source
https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
Three families of decisions
Role-based access control grants permissions to roles and assigns roles to users. Attribute-based access control evaluates policies over attributes of the subject, resource, action, and environment. Relationship-based access control answers whether a path exists between a subject and a resource in a graph, which is how per-object sharing works.
How each model works
RBAC is a join table: user to role, role to permission. It is easy to audit and fast to evaluate, but a role like editor cannot express “editor of document 42” without creating a role per document. ABAC replaces static grants with rules such as subject.department == resource.department && time.hour < 18, evaluated by a policy decision point. ReBAC stores tuples like doc:42#viewer@group:eng#member and resolves transitive membership, as in Google’s Zanzibar design.
In practice, a policy decision point evaluates the model and a policy enforcement point in the API applies the result. Never trust roles supplied by the client; derive them from the authenticated identity.
When to use each
Use RBAC for coarse job-function permissions and admin consoles. Use ABAC when context matters: region, clearance, time, or data classification. Use ReBAC for collaborative products with sharing, folders, and nested teams. Most systems combine all three: a role grants the ability to share, a relationship grants access to a specific folder.
Trade-offs
RBAC is simple but suffers role explosion. ABAC is expressive but policies become code that needs testing and versioning. ReBAC handles sharing elegantly but adds graph latency and consistency questions. All models need decision logging, because “why was this allowed” is as important as the answer.
Example and misconceptions
A document tool assigns the role member, but sharing a single document uses a tuple rather than a new role. An ABAC rule then blocks access outside business hours for contractors.
The common misconception is that one model wins. The real choice is which model owns which decision, and how consistently it is enforced.
Related concepts: Least Privilege, Row-Level Security, and Tenant Isolation.