Exploring how tech giants, such as Google and Netflix, handle authorization for large-scale customer-facing applications gives us insight into the various strategies used to ensure secure access to protected resources. Since most readers are likely familiar with both Google and Netflix as real-world examples of fine-grained access control systems, grasping the technical differences becomes more straightforward.

In summary, Netflix relies on attributes as the foundational elements in its authorization strategy, whereas Google adopts a relationship-based model, leaning on the underlying data. Both platforms offer users granular access controls, but they take distinct approaches to application authorization.

This post delves into the key principles and differences in the authorization approaches employed by Google vs Netflix. Additionally, we provide information on a couple of open-source projects that you can leverage to start implementing resource-level authorization for your applications.

For a more in-depth exploration of the two technical approaches to modern authorization, visit this link or watch the video below.

Google Docs: A real-world example of graph-based authorization

If you’ve ever shared a document using Google Docs or Drive, you’ve indirectly used Google’s unified authorization system, internally named “Zanzibar.” With Zanzibar, Google has created a flexible permissioning system that scales to dozens of applications and many billions of objects. The Zanzibar authorization model revolves around building a graph of named relationships (“viewer,” “editor,” “owner”) between subjects (users/groups) and objects (documents and folders). This model is known as relationship-based access control (ReBAC).

You can share a file, folder or even your entire Drive with other users, and determine the actions they can perform (are they a viewer, commenter, or editor?). You can easily make a user a commenter on one doc, an editor of another, and a viewer of a folder or set of folders. In the same way, you can share a calendar event with a specific user and decide whether they can update the event and/or view the other attendees. You can also easily share or hide your entire calendar from specific users/groups. These are all real-world examples of Zanzibar's ReBAC model.

Since ReBAC is based on a graph of relationships, determining whether a user should have access to a resource entails traversing the graph. If there is a relationship between the user and the resource that carries the correct permission, they will have access.  As a graph, it allows for complex and nuanced authorization rules, including inherited permissions, parent-child relationships, and hierarchies like management relationships. It also supports reverse lookups/indexes to answer the question “Who has access to this resource?” and not just the question “Can this user access that resource?”.

Google has written a technical report that shares the details of Zanzibar and the ReBAC model it uses. The paper has popularized the ReBAC model, and has inspired multiple open-source implementations, including OpenFGA and Topaz. For more about that, go here.

In summary, Google’s approach to application authorization is a graph-based system that is flexible and scalable. It provides billions of users with a clear way to manage access control at various levels. Netflix also built a high-volume fine-grained authorization system, but they took a different approach.

Netflix: A real-world example of attribute-based authorization

Like Google, Netflix offers users granular permissions, which are based on their account type, subscription tier, geo location, etc. And like the search giant, Netflix has also shared the details of its fine-grained authorization system. Unlike Google, it uses an attribute-based system to authorize external users at scale.

Anyone who has ever accessed the streaming platform has been authorized using the attribute-based system. A couple of examples include authorizing access to a show based on the country you are accessing the service from, and restricting access to the billing page to account owners. Netflix’s household sharing is the most recent real-world example of attribute-based access controls (ABAC).

Netflix uses an attribute-based system to authorize external users and enforce its household sharing policy. This method focuses on leveraging various attributes associated with users,  resources, and environments to determine access permissions. Attributes could include devices used to access the service, IPs, geo-location, demographics, time of access, and more. These attributes are then used in authorization policies, authored in a domain-specific language. These policies are written as code and treated just like any other application artifact.

Since the viewer’s location is fundamental for streaming services, as it impacts the available catalog, it makes sense that the streaming giant chose to build an attribute-based system. After all, environmental attributes, like location, are among the main reasons for adopting ABAC over alternative models.

Comparative Analysis: Google vs Netflix

While both Google's ReBAC and Netflix's attribute-based approach aim to protect application resources and provide users with granular permissions, there are some differences between the two:

1. Granularity: ReBAC emphasizes a hierarchical structure, providing fine-grained control at multiple levels. Netflix's attribute-based approach offers dynamic control through various attributes, enabling more contextual access decisions but placing the burden on the developer to express complex relationships, such as inherited permissions and hierarchies. In addition, graph-based ReBAC models support reverse indexes letting you easily answer questions like “Who has access to this resource?” in addition to questions like “Does this user have access to that resource?” This is harder to accomplish with attribute-based systems, which are more open-ended.

2. Flexibility vs. guard rails: Policy-based ABAC systems are extremely flexible and relatively unopinionated, requiring engineers to design the authorization model from first principles. ReBAC systems, on the other hand, have opinions. You need to model authorization rules by defining object types and relationships between them, and then feed a set of object/relation/subject tuples into the system. While this might limit the expressivity of the system, it saves much of the effort of designing a model from scratch.

3. Scalability: Authorization systems require both rules and data in order to operate. In the case of Google's Zanzibar, the rules are simple and fixed, and much of the design of the system is around how to model and process the data. Netflix's approach, leveraging attributes, provides a more flexible system, but requires no less attention to the data architecture. Both systems are built for massive scale and employ sophisticated edge-caching architectures to deliver fast authorization decisions.

4. Ease of implementation and maintenance: Attribute-based systems tend to require more expertise and investment, as developers need to master the policy language while building the system to enforce the policies. Here’s a full comparison of ABAC vs. ReBAC authorization systems.

Both Netflix and Google’s approaches have their strengths and serve as innovative paradigms in the realm of access control. Google's ReBAC focuses on structured, scalable control, while Netflix's attribute-based model emphasizes adaptability and contextual decision-making.

Ultimately, the choice between these approaches depends on the specific needs of the application, balancing factors such as scalability, granularity, and real-time adaptability. Both Google and Netflix have showcased pioneering methodologies that redefine authorization paradigms, setting benchmarks for securing customer-facing applications in the digital era.

Topaz: the best of both worlds

Topaz is an open-source project that lets you combine the best of both worlds and enjoy the benefits of each approach to authorization.

Topaz is a standalone authorization project you can deploy in your cloud to seamlessly implement ReBAC, ABAC and any other authorization model (like RBAC) in your apps in minutes. You can use relationships and attributes in the same policy, or use them separately for different microservices / apps. Regardless of the authorization model, Topaz provides resource-level real-time access control. Check out the repo.

Conclusion

Analyzing popular applications that provide fine-grained authorization is a good way to learn about the underlying access control methodologies.

In this post, we compared the approaches that Google vs Netflix have taken to provide their users with fine-grained access control over the resources managed by their apps. Google has chosen a data-centric, graph-based approach to authorization, which uses the ReBAC model. And Netflix has opted for an attribute-based model, as environmental attributes are foundational to its use-cases.

Netflix and Google have both achieved granular permissions for a high volume of users ranging from tens of millions to billions. Both have secured the resources within their applications, albeit utilizing different methodologies and architectures.

That’s it for now. As always, we’d love to hear what you think! Feel free to drop us a line, or connect with us on our community Slack channel.