Understanding the Access Control Landscape
RBAC vs ABAC: When Roles Aren't Enough
ABAC vs ReBAC: Conditions vs Relationships
Comparing the Models: A Practical Analysis
Hybrid Approaches: The Best of All Worlds
When building modern applications, few decisions impact security, scalability, and user experience as profoundly as how you design access control. Historically, many development teams start with a simple RBAC model and implement the authorization logic in their application code. But as requirements evolve, it often becomes necessary to blend elements of RBAC, ABAC, and ReBAC to meet real-world demands. The idea that these are perfectly distinct models gives the incorrect impression that companies choose one and stick with it, when in reality, teams gradually layer models based on evolving needs.
In this article, we'll examine the three dominant access control models—RBAC, ABAC, and ReBAC—comparing their strengths, limitations, and ideal use cases. We'll help you understand which model (or combination) best suits your application's needs and how to implement it effectively. We’ll also explore how Oso can simplify implementation of fine-grained access control, giving you ultimate flexibility to model your data.
Access control is fundamentally about answering a simple question: "Who can do what with which resources?" The way that you answer that seemingly simple question depends on who the users are, how the resources are structured, and what context (i.e. organization, timing, geography) matters.
RBAC is the most widely adopted access control model. It assigns permissions to roles, and users inherit those permissions when assigned to roles.
With RBAC, users have defined roles that determine the data that they can access. It works best for organizations with well-defined job functions and hierarchies.
For example, in a content management system:
RBAC is the simplest approach to understand, making it a common starting point when development teams are implementing a “DIY” solution. However, RBAC doesn’t provide the fine-grained controls that most modern applications demand, and as a result, many teams extend their permissions to include relationship-based or attribute-based models.
ReBAC focuses on the relationships between entities in your system. Rather than assigning permissions directly or through attributes, ReBAC leverages the connections between users and resources.
Let’s continue with the CMS example from the RBAC section. Let’s say a user creates a folder of documents stored within the CMS. If you have viewer access to the folder, you should have viewer access to all of the documents in that folder. Now we need to implement ReBAC, which means that not only do you need roles, but you also need to organize permissions based on the relationship between resources: in this case, which documents are in which folders.
ReBAC is best suited for scenarios with complex hierarchies and interconnected data. For example, in a document management system, ReBAC can easily express policies like "users can access all documents in projects they're assigned to" without having to tag each document individually.
ABAC takes a more dynamic approach by making access decisions based on attributes of users, resources, actions, and environment. It is the most flexible access model, but also the most complex to implement and maintain.
ABAC allows for highly granular control through conditions and attributes. Extending our CMS example further, you may want to mark some documents “public.” A public document can be viewed by all users, regardless of which folder it’s in. The policy now incorporates the “public” attribute of a document into its authorization logic.
While RBAC provides a solid foundation for access control, it can become unwieldy as applications grow in complexity. The number of roles required to meet permissioning needs often explodes, creating an operational burden. Or, even worse, roles are insufficiently granular and have more access than they should, creating a security risk.
RBAC works well when access patterns align neatly with organizational roles. However, it struggles with:
When these challenges arise, many organizations turn to ABAC. While both RBAC and ABAC secure systems and data, the way that they assign and manage permissions differs significantly.
ABAC supports significantly more granular permissions than RBAC by considering multiple factors in access decisions:
Yet this flexibility comes at a cost: ABAC models are harder to reason about than RBAC models. They require more careful planning and can be challenging to audit and troubleshoot.
Now let’s explore the other major alternative to RBAC: ReBAC. Both ABAC and ReBAC offer fine-grained access control, but they approach the problem differently.
ABAC excels in scenarios requiring complex conditional logic based on multiple attributes. Consider a sophisticated system where access depends on various factors like time, location, and user status.
For example, ABAC can easily express policies like: "A guest can only order a specific drink after midnight if they're seated at the bar." This combines time attributes, location attributes, and user attributes into a single policy.
ReBAC leverages the inherent relationships in your data model to simplify access control. Instead of tagging each resource with attributes, ReBAC uses the connections between entities.
Imagine a user named Jay who has a locker containing various items. With ABAC, you might tag each item with "Owner=Jay." With ReBAC, you simply define a policy: "A guest can access all items inside their own locker." The relationship between Jay, his locker, and the items inside creates a natural access control structure.
ReBAC particularly shines in:
To sum it up, different models suit different application types:
In practice, many sophisticated applications use a combination of models to address different access control needs. These applications use RBAC for broad permissions, ABAC for context, and ReBAC for structure.
RBAC provides a solid foundation for coarse-grained access control. It's intuitive for administrators and developers alike, making it an excellent starting point.
Example use case for RBAC: analyst can view reports
ABAC can supplement RBAC when you need context-sensitive permissions. For example, a basic role might grant access to financial reports, while ABAC conditions restrict access based on time, location, or report sensitivity.
Example use case for RBAC and ABAC: analyst can view reports during business hours
ReBAC excels at handling permissions that follow your data's natural relationships. In many cases, RBAC and ABAC policies can be combined with ReBAC-based policies, with hierarchies enforced by ReBAC and more fine-grained access managed by ABAC.
Example use case for RBAC and ReBAC: Manager can access files owned by their team
Finally, there are some scenarios where all three models are required.
Example use case: Doctor can access patient files in their department, if on call, and if patient consent is present
resource Document{
roles = ["reader", "editor", "admin"];
permissions = ["read", "edit", "delete"];
relations = { folder: Folder};
# RBAC - document permissions determined by role on document
"read" if "reader";
"edit" if "editor";
"delete" if "admin";
# Role inheritance: editors are readers; admins are editors
"reader" if "editor";
"editor" if "admin";
# ReBAC - document permissions inherited from folder permissions
"reader" if "viewer" on "folder";
"editor" if "writer" on "folder";
"admin" if "admin" on "folder";
# ABAC - all users can read public documents
"read" if is_public(resource);
}
When implementing access control, consider these factors:
Implementing a homegrown ABAC or ReBAC solution often requires building custom logic into your services, syncing role or relationship data manually, and duplicating logic across endpoints. For this reason, many organizations are moving toward authorization as a service solutions like Oso to simplify permissions.
This approach separates authorization logic from application code, providing:
With Oso, the various access models become composable: you define roles, attributes, and relationships declaratively in one place, and Oso handles enforcement, testing, and propagation.
Selecting the right access control model depends on your specific requirements:
Access models differ in conceptual complexity: RBAC is easiest to reason about, ABAC introduces conditional logic, and ReBAC models complex relationships between users and resources. Ask yourself:
In a DIY system, these factors translate directly into implementation effort.
With Oso, we decouple those concerns. You still need to think carefully about which model(s) make sense for your application — but implementing even the most advanced model (like ABAC) becomes dramatically easier. Oso gives you the tools to model relationships, conditions, and roles in a unified, testable, and maintainable way.
The choice between RBAC, ABAC, and ReBAC isn't about finding the "best" model—it's about finding the right fit for your application's needs. Many successful systems use a combination of approaches, leveraging the strengths of each model where appropriate.
As applications grow more complex and interconnected, we're seeing a shift toward more sophisticated access control models like ABAC and ReBAC. These models provide the fine-grained control needed for modern applications while addressing the limitations of traditional RBAC.
Whatever model you choose, remember that access control is a fundamental aspect of application security and user experience. Investing time in designing the right approach will pay dividends throughout your application's lifecycle.