Modern authorization for applications is gaining traction. Over the past year, we’ve seen more awareness of the concept of externalized authorization than ever before. We’ve also seen growth in open-source projects dedicated to helping developers implement these systems and provide resource-level authorization to end-users.

With that said, modern authorization is quite new and emerging markets can be confusing. There are multiple approaches, use-cases, models, policy languages, and decision engines…Most can’t see the forest for the trees.

In this post, we attempt to alleviate some of the confusion by sharing real-world examples of two popular use-cases enforced by modern authorization models. Read on to explore how Airbnb authorizes external users using relationship-based access control (ReBAC), and Uber uses attribute-based access control (ABAC) to authorize internal users.

Airbnb: ReBAC for external users

Airbnb’s marketplace caters to different types of entities, and each entity is assigned different permissions. We have anonymous browsers, guests, and hosts as external users. A browser can view a listing, a guest can create a reservation for that listing, and a host can accept that reservation and edit the listing.

Users can also gain access to certain resources based on conditions. This is where we can see examples of fine-grained access controls. For example, only guests with a reservation can see the listing’s address, and they can only access more granular details, like how to get inside or the wifi password, during their stay.

In early 2021, Airbnb wrote about its fine-grained authorization system: Himeji. Inspired by Google’s Zanzibar paper, Himeji is a graph-based authorization system that uses ReBAC as its model. Built for scale, Himeji stores tens of billions of relations and performs nearly a million authorizations a second!

Resource-level authorization with ReBAC

ReBAC is an opinionated model that requires us to model the domain into object/relation/subject tuples and build a graph of users and objects via relations. In this model, the relationships between subjects (users/groups) and objects (listings, reservations, etc.) govern access. For example, the following tuple represents an Airbnb listing that is owned by Jane Doe: listing:<listing-id>/host/user:jane@doe.com. As the host, Jane can edit the listing, update the availability, accept or reject bookings, and even remove the listing from Airbnb.

When we say that ReBAC is graph-based, we mean that the relationships between users, and resources are represented as a graph. Each node in the graph might represent a user or a resource, with the edges (i.e links between nodes) defining the relationships between them. As a graph, it can be traversed in both directions, allowing us to answer questions like “Does this user have access to that resource?” as well as “Who are the users that have access to this resource?” It also natively supports inherently hierarchical permissions, such as parent-child relationships, containment, and other complex relationships.

ReBAC is a powerful model that allows developers to build resource-level permissions for a wide number of use cases. But there are scenarios where we might be better off using ABAC as the authorization model. These include applications that cannot describe authorization rules as relationships between subjects and objects, or those who use attributes as foundational elements of their policies.

Uber: ABAC for internal users

Like Airbnb, Uber offers different permissions and experiences for diferent user types (i.e riders and drivers). A rider can request rides, which a driver can accept or cancel. And here too we have resources that become available based on conditions: only drivers within a certain distance of the rider can accept the ride, and a rider will only see the details of the driver and vehicle once their ride has been accepted. But, as opposed to Airbnb, most of the complexity in authorization logic relates to the access employees need in different scenarios.

Last year, the ride sharing pioneer wrote about implementing ABAC across 70 services using Charter, their centralized authorization system. They found that certain services required the ability to define authorization logic based on attributes. For example, a payment support service might want to limit access to payment information to only customer support representatives that are in the same region. Indeed, environmental attributes are among the leading reasons for organizations to choose ABAC vs ReBAC.

Granular permissions with ABAC

ABAC is a flexible and scalable access control model that uses attributes of the user (rating, number of rides, user id, etc.), resources (car, ride, credit card, etc.), or environment (location, device, time of day, etc.) to determine access. It’s flexible enough to support almost any authorization logic. But it doesn’t support reverse indexes, which would allow us to answer questions like “Who are all the users that have access to this resource?” in addition to “Does this user have access to that resource?” Moreover, some hierarchical inherited relationships can be harder to express using attributes.

With that said, there are a number of real-world scenarios where attributes provide more elegant solutions than relationships. Conditions that hinge on environmental attributes, such as location, network, time of day, etc., come to mind. Another prime example is a disabled attribute that can be added to an employee that leaves the organization to deny that user access to every resource.

We believe that there is value in both models. In fact, most applications would benefit from using both relationships and attributes for authorization. This is why we built our open-source authorizer, Topaz, to support both ABAC and ReBAC (as well as RBAC) out of the box.

Topaz: the best of both worlds

While we can try to fit an application into one model or the other, some authorization decisions are better expressed using attributes and others through relations. The Topaz open-source authorizer lets us use both attributes and relationships to authorize an application. It is the only open-source project to enable the combination of authorization models in a single application.

In addition, Topaz is fast, making authorization decisions in ~1ms. It’s flexible enough to support every authorization model, including ABAC and ReBAC, and it’s simple enough that a single developer can get started with fine-grained authorization in minutes and be production ready in 1-2 weeks. Check out the repo and let us know what you think about it on Slack!

Conclusion

In this post, we explored real-world examples of ABAC and ReBAC. We saw how Airbnb uses a relationship-based model to authorize external users and Uber uses an attribute-based model to authorize internal users. We then explored the differences between these models.

ABAC and ReBAC both enable granular permissions, with each shining in different scenarios. Applications with hierarchies, inherited permissions, and other complex relationships would find the most value out of ReBAC. And apps that use attributes as foundational elements in their authorization logic would find ABAC to be a better fit.

But there’s no reason to limit ourselves to a single model throughout the application. There are many scenarios that would be better expressed in one rather than the other. Topaz lets developers use ABAC and ReBAC interchangeably throughout the application. It’s fast, flexible, and easy to implement with any application. A complete set of SDKs, APIs, templates, and guides are available to help you get started with fine-grained authorization. You can also join the community Slack to engage with the community and maintainers.