Authorization BACk to basics: RBAC vs. ReBAC

An employee, partner, customer, or supplier logs into your application — do you know what they can access? 

It’s a delicate balance. If a user doesn’t have enough access, they might be unable to do their job, access a valuable resource, or complete a transaction. If a user has too much access, they might encounter sensitive information or take actions that can put your business at risk. 

That’s where authorization comes in. When someone attempts to access an application or resource, we need to confirm they are the real user (authentication) and they have the right access to the right resources for the right amount of time (authorization). 

There are a few methods for implementing authorization, two of the most popular being role-based access control (RBAC) and relationship-based access control (ReBAC). 

RBAC is a method of restricting access to resources based on their role. In RBAC, each user has an assigned role, such as employee, manager, customer, or partner. An admin can specify which resources each role should have access to and the actions they can take on each resource. Some of the most common access and action rules are: create, read, update, and delete. These rules allow users with a particular role to create an object, read an object, update an object, or delete an object. An admin might also assign more than one access or action rule to a role.

Let’s look at an example. A major healthcare provider with clinics nationwide might have roles for patients, doctors, nurses, office staff, and pharmacists. Let’s think of a scenario where a patient visits a clinic and receives a prescription. Within an RBAC model, an IT admin would assign each user a role. Based on that role, they would further define that

• Patients should have access to read their prescriptions
• Doctors should have access to create, update, and delete a prescription
• Pharmacists should have access to read, update, and delete a prescription
• Nurses should have access to read a prescription
• Office staff should not have any access to the prescription

With RBAC, you don’t need to update the authorization model each time someone changes positions or leaves the company. Since access rights are assigned based on roles, that user automatically inherits permissions based on their assigned role. 

In situations where more fine-grained access control is needed, RBAC isn’t the best fit. In our scenario above, it would be difficult to define which patients’ prescriptions each doctor should have access to or which pharmacists should be able to modify a given prescription. 

Now, let’s look at ReBAC. An evolution of RBAC, ReBAC looks at the relationship the user has within the authorization model to make the access decision instead of restricting access to resources based on the user’s assigned role.

Let’s take our healthcare example above and see what it might look like using ReBAC. Within the authorization model, the patient is related to a specific doctor at the clinic, and the admin can specify that the doctor should have access to view or modify the medical records associated with that patient, including the prescription. Any other doctor at the clinic that is not related to the patient cannot view the prescription or any other health records for the patient. Likewise, each doctor is related to a nurse, so the nurse can view the records of any patient associated with the doctor they’re related to. Within their patient profile, the patient has specified their preferred pharmacist, so that pharmacist is related to the patient and can read, modify, and delete their prescription.

What do you notice? First, we can get much more granular with our access rules and control. We can also manage more complexity as our organization grows andh more users need access to an exponentially increasing number of resources. Instead of defining roles for each new resource or vice versa, our authorization model can make an access decision based on the relationships this new resource or user has within the model. Pretty effective. 

Things to consider when implementing ReBAC 

• You have to provide the ReBAC tool with all of the data required to make authorization decisions. Providing this data adds complexity — especially for an organization with many different user types, applications, and resources.
• If you’re implementing an authorization model on your own, it can be complex to define the relationships within an authorization model using ReBAC. 
• Depending on your ReBAC tool, it can be difficult to perform audits to know what a user can access. 

Despite these prerequisites, the benefits of implementing ReBAC will far outweigh the drawbacks for many organizations — especially if you choose a powerful platform for implementing authorization. 

Speaking of powerful platforms, if you’re ready to dive deeper into authorization, check out OpenFGA from Okta. OpenFGA enables developers to implement relationship-based access control that’s fast, scalable, and easy to use.