Scaling Permissions with ReBAC: A Guide to OpenFGA and Zanzibar

Most developers start their authorization journey with a simple boolean flag: is_admin. As the application grows, this evolves into Role-Based Access Control (RBAC), where users are assigned roles like 'Editor' or 'Viewer'. For many systems, RBAC is sufficient. However, as you scale into distributed architectures or build collaborative platforms like Google Drive, GitHub, or Figma, RBAC quickly becomes a bottleneck.

In these environments, permissions aren't just about who you are; they are about how you relate to the data. This is where Relationship-Based Access Control (ReBAC) and the Zanzibar model come into play. This article explores how to implement ReBAC using OpenFGA to build fine-grained, scalable authorization systems.

The Limitations of RBAC in Modern Systems

RBAC works well when permissions are coarse-grained. If you want to allow all 'Managers' to view all 'Reports,' RBAC is your best friend. But consider a scenario where a user needs to share a specific document with a specific colleague, or where access is inherited through a nested folder structure.

In a traditional RBAC system, you might end up with an explosion of roles (e.g., Folder_123_Viewer) or a complex mess of Attribute-Based Access Control (ABAC) logic scattered across multiple microservices. This leads to several problems:

1. Logic Fragmentation: Authorization logic is duplicated across services.
2. Scalability Issues: Checking deep hierarchies (e.g., folder -> subfolder -> file) requires expensive recursive database queries.
3. Auditability: It becomes nearly impossible to answer the question, "Who has access to this resource?" across the entire ecosystem.

Understanding the Zanzibar Model

In 2019, Google published a whitepaper titled "Zanzibar: Google’s Consistent, Global Authorization System." It described the system powering permissions for Drive, YouTube, and Cloud. Zanzibar introduced a paradigm shift: treating authorization as a graph problem rather than a set of rules.

At its core, Zanzibar uses Relationship Tuples to represent access. A tuple follows a simple format:

object#relation@user

For example:

• doc:budget_2024#viewer@user:alice (Alice is a viewer of the 2024 budget document)
• folder:finance#parent@folder:root (The root folder is a parent of the finance folder)

By representing permissions as a graph of relationships, Zanzibar can perform high-performance lookups, even across billions of objects and users, by traversing these edges.

Enter OpenFGA

OpenFGA (Fine-Grained Authorization) is an open-source implementation of the Zanzibar model, originally created by Auth0 and now a CNCF Sandbox project. It provides a developer-friendly way to define authorization models using a Domain Specific Language (DSL) and offers a high-performance API for checking permissions.

The OpenFGA Architecture

Unlike traditional libraries that run inside your application process, OpenFGA is typically deployed as a centralized service. Your microservices communicate with OpenFGA via a simple API. This decoupling allows you to centralize your authorization policy while keeping your data distributed.

Defining the Authorization Model

In OpenFGA, you define your schema using a DSL. Let's look at a real-world example: a collaborative project management tool.

model
  schema 1.1

type user

type organization
  relations
    define member: [user]
    define admin: [user]

type project
  relations
    define parent_org: [organization]
    define owner: [user]
    define contributor: [user] or owner
    define viewer: [user] or contributor or member from parent_org

In this model:

• A project has an owner, contributor, and viewer.
• We use Relationship Composition: A contributor is also automatically an owner (via or).
• We use Transitive Relationships: A viewer can be a specific user OR anyone who is a member of the parent_org.

This inheritance logic is handled by OpenFGA, not your application code.

Implementing ReBAC in Your Workflow

To integrate OpenFGA into a distributed system, you follow a three-step cycle: Write, Check, and List.

1. Writing Relationship Tuples

Whenever a state change occurs in your application (e.g., a user creates a project or shares a file), your service should write a relationship tuple to OpenFGA.

// Example: Alice creates a project
await fgaClient.write({
  writes: [
    {
      user: 'user:alice',
      relation: 'owner',
      object: 'project:new-app-launch'
    }
  ]
});

2. Checking Permissions

When a user attempts an action, your API gateway or microservice performs a check call. This is the core of ReBAC. OpenFGA traverses the graph to determine if a path exists between the user and the resource.

const { allowed } = await fgaClient.check({
  user: 'user:bob',
  relation: 'viewer',
  object: 'project:new-app-launch'
});

if (!allowed) throw new ForbiddenError();

Notice that the application doesn't need to know why Bob is a viewer. Bob might be the owner, or he might be a member of the organization that owns the project. OpenFGA handles that complexity.

3. Listing Objects

A common requirement is showing a user a list of all resources they can access. In a traditional DB, this is a SELECT * WHERE... with complex joins. In OpenFGA, you use the ListObjects API.

const { objects } = await fgaClient.listObjects({
  user: 'user:alice',
  relation: 'viewer',
  type: 'project'
});
// Returns ['project:new-app-launch', 'project:marketing-campaign']

Solving the "NewSQL" and Consistency Problem

One of the biggest challenges in distributed authorization is the "New Cookie Problem." If a user is removed from a group, that change must be reflected immediately to prevent unauthorized access.

Zanzibar (and OpenFGA) solves this through the use of Consistency Tokens (often called zedtokens or continuation_tokens). When you write a relationship, you get a token back. When you perform a check, you can pass that token to ensure the check is performed against a version of the database that is at least as fresh as that token. This balances the need for high availability with the requirement for causal consistency.

Real-World Benefits of the OpenFGA Approach

1. Unified Policy, Distributed Data

Your authorization logic lives in one place (the OpenFGA model), but your data (users, projects, files) stays in their respective microservices. This prevents the "spaghetti code" of permission checks across your codebase.

2. Handling Deep Hierarchies

Consider a file system with 10 levels of nested folders. In a relational database, checking if a user has access to a file at the bottom level requires a recursive CTE or multiple queries. In ReBAC, it's a simple graph traversal that OpenFGA optimizes using caching and parallel execution.

3. Future-Proofing

Requirements change. Today, only owners can delete projects. Tomorrow, "Security Auditors" might need delete permissions for compliance. With ReBAC, you update the model in OpenFGA, and the change is instantly applied across all services without a single line of application code changing.

Practical Challenges and Considerations

While ReBAC is powerful, it isn't a silver bullet. Here are some things to keep in mind:

• Latency: Every permission check is now a network call. While OpenFGA is fast (sub-10ms checks), you should consider using sidecars or local caching for high-traffic endpoints.
• Data Synchronization: You must ensure that your application database and OpenFGA stay in sync. If a project is deleted in your DB but the relationship remains in OpenFGA, you have "ghost" data. Implementing robust transactional outbox patterns can help mitigate this.
• Modeling Complexity: It's easy to over-engineer your model. Start simple. Don't try to model every possible attribute as a relationship. Use ReBAC for structure and relationships; use simple application logic for ephemeral state (like "is the user's subscription active?").

Conclusion

Moving from RBAC to ReBAC is a significant architectural decision, but for complex, distributed systems, it is often the only way to maintain sanity and scale. By adopting the Zanzibar model via OpenFGA, you decouple authorization from business logic, gain the ability to handle complex hierarchies, and provide a consistent security posture across your entire stack.

Actionable Next Steps:

1. Audit your current logic: Identify areas where you are performing recursive database queries to check permissions.
2. Experiment with the OpenFGA Playground: Map your current roles into a relationship model to see how the DSL handles your edge cases.
3. Start Small: Implement ReBAC for a single resource type (e.g., 'Documents') before migrating your entire authorization layer.