RBAC grants access by role. ABAC grants access by attribute. Learn the 7 key differences, when each model breaks down, and how to choose the right one for your system.
How Apple broke "Sign in with Apple" with an unannounced and silent redirect
Framing RBAC vs ABAC as a binary choice misses how most production systems actually work. Real authorization layers usually run both. The interesting question isn't which model to pick. It's which model to start with, what signals tell you you've outgrown it, and where the third model (ReBAC, which most comparison articles forget) belongs in your stack.
The seven concrete differences below cover the architectural split, but also role explosion (the failure mode that drives teams to ABAC in the first place), the hybrid pattern that most mature systems land on, and where Google's Zanzibar-derived ReBAC fits when both RBAC and ABAC start to creak.
Role-Based Access Control (RBAC) is an authorization model that grants users permissions based on their assigned role within an organization, where each role carries a fixed set of access rights.
The mechanics are straightforward. An admin defines roles (Admin, Editor, Viewer). Each role gets a set of permissions (read, write, delete, publish). Users are assigned to roles. At request time, the system asks: "does this user's role include this permission?" The answer is yes or no.
A SaaS example: in a content management product, an Editor can publish articles, a Viewer can only read them, and an Admin can manage both. Three roles, three permission sets, easy to reason about, easy to onboard new users into.
RBAC dominates because it's easy. Easy to reason about. Easy to audit. Easy to onboard new users into. Most IAM tooling supports it natively. For compliance audits where role-to-permission mapping has to be documented, RBAC gives you a clean answer in a spreadsheet. SOC 2 auditors love it because the model maps cleanly to the question they're going to ask: "show me who has access to what."
The trap is that the simplicity is also where the failure mode lives. Easy-to-add roles means it's also easy to keep adding them, and that's where role explosion starts.
Attribute-Based Access Control (ABAC) is an authorization model that evaluates a set of attributes (about the user, the resource, the action, and the environment) to make dynamic, context-aware access decisions at runtime.
ABAC policies operate on four attribute categories:
A healthcare example puts this in perspective: a doctor in the cardiology department can access patient records for their own department, only during business hours, only from approved devices. RBAC alone can't express that policy without creating roles like "cardiology_doctor_business_hours_approved_device," which is the textbook definition of role explosion.
ABAC suits regulated industries because it can enforce fine-grained policies without creating hundreds of roles. GDPR data minimization, HIPAA minimum necessary access, and CMMC-level compliance often require access controls that go beyond what static roles can express. ABAC handles those policies natively, where RBAC ends up modeling around them with role workarounds that nobody enjoys auditing.
RBAC and ABAC differ across seven key dimensions: how permissions are defined, decision granularity, scalability, implementation complexity, dynamic vs static access decisions, compliance suitability, and operational overhead.
Both can be compliant. They're compliant in different ways and for different regulators.
Most teams underestimate ABAC's setup cost and overestimate the long-term cost of running it. The opposite is true for RBAC.
| Dimension | RBAC | ABAC |
|---|---|---|
| Permission model | Static roles with fixed permissions | Dynamic evaluation of attribute combinations |
| Granularity | Role-level (all users in a role share access) | Resource-instance level (per-user, per-resource) |
| Scalability | Good initially; role explosion at scale | Flexible; attribute complexity increases at scale |
| Implementation | Low initial cost; most IAM tools support it | Higher initial cost; requires policy engine |
| Access decisions | Static (changes require admin reassignment) | Dynamic (context-aware at runtime) |
| Compliance fit | Org charts, audit trails, RBAC-native standards | HIPAA, GDPR, FedRAMP, CMMC, data-level policies |
| Operational overhead | Low to run; high when roles proliferate | High to set up; lower marginal cost to scale policies |
RBAC is the right default when your organization has stable, well-defined roles, fewer than ~50 distinct permission patterns, and doesn't need to enforce access based on context like time, location, or resource sensitivity.
These are the role-explosion early warnings worth taking seriously. If any of them are showing up in your access reviews, RBAC has hit its ceiling for your environment:
ABAC is the right choice when access decisions have to account for context (time, device, data sensitivity, location) or when compliance frameworks require policies that can't be expressed through static roles alone.
The operational cost of ABAC is real and often underestimated. Attribute sprawl happens when attributes get added without governance. Policy testing complexity scales nonlinearly: past a few dimensions, testing every combination becomes intractable. Policy engines also require their own infrastructure, monitoring, and team familiarity to run well. Teams that move to ABAC without budgeting for the operational ramp tend to end up with policies they can't reason about, which is worse than the role explosion they were trying to escape.
Most production authorization systems combine RBAC and ABAC: RBAC establishes broad role-level access boundaries, while ABAC layers in dynamic, attribute-driven policies for fine-grained decisions within those boundaries.
RBAC handles the structural question: "Is this user a member of the engineering org?" ABAC handles the contextual question: "Can this engineering member access this specific dataset, given their clearance, the data's sensitivity, and the current time?"
The two layers are complementary, not competitive. RBAC gives you the org-chart gates. ABAC gives you the policy refinements inside those gates. Most mature stacks land here naturally, even when they started out trying to pick one model.
Yes, and in most non-trivial systems they should be. The hybrid model isn't a compromise. It's the default for mature authorization systems. The binary framing in most comparison articles exists because it makes the article easier to write, not because it reflects how production systems actually work.
See how Ory Keto handles RBAC and ReBAC patterns
RBAC is not outdated. It remains the most widely used access control model in production, and that's not changing. But it's architecturally incomplete for systems with complex resource hierarchies, collaborative sharing, or permission inheritance requirements. That's where ReBAC enters.
Both models struggle with hierarchical, resource-sharing scenarios. "All editors of a folder can edit its files." "Members of a team inherit access to team resources." "Anyone shared on this document can view it, plus anyone in their organization who has been granted blanket access through a parent group."
These permission patterns are hard to model cleanly in RBAC (role explosion) and difficult to model performantly in ABAC (attribute graph traversal at query time gets expensive fast). This is the problem space ReBAC solves, and why Google built Zanzibar internally to handle permissions across Drive, YouTube, and Photos.
Relationship-Based Access Control defines permissions through the relationships between entities rather than role assignments or attributes. Instead of "user has role editor," it's "user has relation editor on document_123." Permissions emerge from traversing the relationship graph. Add a user to a team, and they inherit access to everything the team is connected to.
ReBAC is the model behind Google Drive, GitHub's org permissions, and Ory Keto. For a deeper look at the model's origins, how Ory Keto evolved from Google Zanzibar covers the architecture.
The right authorization model depends on three factors: how complex your access requirements are today, how frequently they change, and what compliance obligations you need to meet. Most mature systems end up implementing all three models in layers.
The honest answer for most teams: you're going to need at least two of these models, and the question is which one to start with and how to evolve. Starting with RBAC and adding ABAC or ReBAC layers as needs grow is the most common production pattern.
The open source authorization space has matured significantly. OPA (Open Policy Agent) is a general-purpose policy engine widely used for ABAC. Casbin is a multi-paradigm library that supports several models. SpiceDB is a ReBAC-focused permissions service. And Ory Keto is an open source authorization framework built on Google's Zanzibar relationship-based access control model that also supports RBAC patterns.
For engineering teams that need a production-ready authorization framework capable of implementing RBAC patterns, attribute-based policies, and relationship-based access control in a single system, Ory Keto is built on Google's Zanzibar model, the same architecture that powers access control at Google Drive and YouTube scale. It separates authorization logic from application code entirely: teams define access policies as relationships between subjects and resources, while Ory Keto evaluates them consistently at runtime without requiring application-layer permission checks.
For implementation depth on the policy syntax, see Ory Permission Language. For real-world deployment context, API access control in Kubernetes environments shows how this pattern works in cloud-native production. And for AI-specific use cases that are growing fast, access controls for AI and LLM systems covers an emerging category most authorization tools don't handle well.
Read the Ory Keto documentation
The "RBAC or ABAC?" question is usually the wrong question. The right question is: "what does my access control model need to express today, what will it need to express in 18 months, and which model (or combination) gets me there without rebuilding?" Teams that ask the right question early avoid the most painful authorization rewrites. Teams that don't end up doing them twice, often in the same year. Either way, the broader customer identity and access management discipline is where access control lives, and authorization is just one of the pillars worth getting right.
