When individuals log in to your application, whether they’re team members, collaborators, clients, or external stakeholders, a crucial question arises: Do you have a clear understanding of what they can access? Striking the right balance is vital — too little access may hinder their tasks, while too much could risk exposing sensitive information.
Giving individuals access to sensitive information involves user authorization, a vital aspect of software development. The authorization model you choose will control and restrict access appropriately while providing a seamless experience for authorized users.
Two ways to implement authorization are role-based access control and relationship-based access control, or RBAC and ReBAC. In this article, we’ll explain their key differences to help you choose one (or both) for your next project. You can also view the video below for a developer-focused introduction to authorization concepts.
What is role-based access control (RBAC)?
Role-based access control is a system that automates authorization for specific actions (e.g., logging in or accessing protected data) by analyzing the user’s role(s) defined for the particular account.
Roles are technical features of the account typically associated with aspects like:
A user’s job title, responsibilities, or job functions
A user’s seniority or position in the organization
Custom defined roles based on the app’s context
Factors like these ultimately determine whether the user can access a system controlled by RBAC.
The simplest way to conceptualize RBAC is as a yes/no question. Users are assigned roles, and those roles grant certain permissions. If the specific action users are attempting falls within the defined scope of permissions for their roles, they will be authorized to perform the action.
If the action doesn’t align with the permissions granted to the role, then authorization will not be granted; the user (or attackers pretending to be the user) are restricted.
An RBAC example
Let's explore an RBAC implementation example.
Consider a scenario in which you operate a cloud-based collaboration platform catering to diverse industries. Your platform offers a range of functions to enhance team collaboration, project management, and document sharing.
Without RBAC, internal teams and external collaborators could access and modify any aspect of the collaboration hub, project management suite, or document repository. This lack of access control might lead to confusion and compromise project integrity, especially in environments where tasks are specific to different teams or departments.
Implementing RBAC (for example, with roles like Admin and User) ensures that each user, whether internal or external, only accesses the features and data relevant to their roles and responsibilities. This enhances operational efficiency, maintains data integrity, and streamlines collaboration across diverse teams within your platform.
Benefits and potential downsides of RBAC
RBAC is easy to configure relative to other authorization models. The simplicity makes for quick implementation and lower overall resource costs.
Many B2B RBAC use cases involve organizational contexts with few users, an absence of complicated data sensitivity requirements, or easily differentiated user roles. For example, in a smaller organization with relatively few users who do not often come into contact with regulated information, a simple RBAC system would likely meet their needs.
However, there is the potential for “role bloat” or “role explosion” as users accumulate more permissions over time. Both UX and management may become more complex as organizations scale upward, which could also raise security concerns. RBAC is also not the best fit in complex environments with multi-level hierarchies and the need for context-based access.
What is relationship-based access control (ReBAC)?
Like RBAC, relationship-based access control is a mechanism for organizations to add authorization to their apps. However, the questions are more complex than the simple yes/no used for RBAC.
Instead, ReBAC considers relationships between entities in the application’s context. Entities could be anything from users, resources (like a portal or a doc within the app), groups (collection of users or resources), and hierarchies.
For example, when a user attempts to perform an action on a resource, the ReBAC system may analyze:
Whether the user owns the resource (i.e. did the user create the resource)
The relationship between the user / their group and the resource
Whether there is a parent-child relationships between the user and the resource (i.e. is the resource part of a folder that the user has / does not have access to)
If the ReBAC system determines that relationships are as they should be, then the action is authorized. If it doesn’t, the action will be restricted.
A ReBAC example
Let’s consider the same example used in the RBAC section of a cloud-based collaboration platform.
Rather than just having roles like Admin and User (which can be done with an RBAC system), ReBAC enables organizations to craft relations such as:
A user that has created a document can edit, delete, and share the document with others.
While sharing the document, the owner can assign roles such as Editor, Commenter, and Viewer to the people they are sharing it with.
A user that has access to a folder automatically has access to all the files within that folder.
Users can be clubbed into groups (e.g. HR, IT, Marketing) and automatically granted access to relevant resources.
ReBAC ensures that access is not solely determined by formal roles but is dynamic, considering the evolving relationships within the platform. It provides a flexible and granular access control model that aligns with the fluid nature of complex and evolving apps.
Benefits and potential downsides of ReBAC
In contrast to RBAC, ReBAC provides unmatched customization when creating relationships. As a fine-grained access control model, ReBAC delivers more flexibility and control over access decisions.
By defining relationships between users, resources, and other entities, organizations can be sure that authorization is working in the ways it should be. However, this flexibility and assurance comes at potentially higher upfront costs and time.
Assigning and analyzing variables in isolation and relation to each other requires a lot of both human and computing bandwidth. There is more expertise and training to account for, as well as the potential support needed to cover edge cases.
How to choose between RBAC and ReBAC
When comparing RBAC and ReBAC for your next software project, here’s how they stack up:
| RBAC | ReBAC |
|---|---|---|
Methodology | Users’ defined roles and permissions determine whether an action is authorized or not | Relationships between the user, the object, and the context determine whether actions are authorized |
Security assurance | RBAC’s relatively simple configurations can provide a moderate amount of control, visibility, and security | ReBAC’s intricate rules and relationships allow for deep and complex access control and threat mitigation |
User experience | Role explosion has the potential to complicate users’ everyday data interactions | With sound relationship management, users enjoy seamless access to data |
Setup and maintenance | Roles are relatively easy to define, assign, and manage over time, but the threat of bloat must be addressed | Relationships are complex and require acute attention to detail, which could incur upfront and ongoing costs |
Implementation | Low implementation complexity compared to other AuthZ models | High implementation complexity compared to other AuthZ models |
Depending on a customer’s client base and the make-up of their clients’ user bases, RBAC's relative simplicity and lower security assurance might make the most sense. Or, the trade-off of more granular access control and tighter security for potentially higher costs might make ReBAC the better choice.
And, in some cases, both systems might provide value for your business.
Can you use both RBAC and ReBAC?
Yes! Organizations can provide both RBAC and ReBAC options across an app, website, or other software project. Depending on the use case, clients may require both models for different end users or want to configure a system that applies both to all accounts.
In fact, most ReBAC implementations do have roles as a key part of the authorization schema. However, the roles are not just assigned static permissions, but a deeper level of dynamic permissions that take the resource and other factors into account.
Fine-grained authorization with Descope
As you navigate the intricacies of access control models, we understand the importance of choosing the right solution for your unique requirements. At Descope, we help organizations easily add RBAC, ReBAC, and ABAC capabilities to their apps, ensuring the right level of authorization flexibility and control for their needs. Watch this demo video to see Descope ReBAC added to a sample note-taking application.
Ready to get started with Descope? Sign up for a Free Forever account and check out our documentation to explore our SDKs and APIs. Have questions about our platform or about authorization in general? Book time with our auth experts to learn more.
