Policy-based access control (PBAC) and relationship-based access control (ReBAC) represent two distinct architectural patterns for managing authorization. PBAC evaluates permissions using policies that consider attributes and context, while ReBAC determines access by traversing a graph of stored relationships between users and resources. Understanding their fundamental differences in data modeling, performance characteristics, and operational overhead is crucial for selecting the right approach for a given application architecture.
What PBAC does
Policy-based access control decouples authorization logic from application code by expressing rules in a dedicated policy language. This model is often used as an umbrella term for attribute-based access control (ABAC), where decisions depend on attributes of the user, resource, action, and environment. A central component, the Policy Decision Point (PDP), evaluates incoming requests against a set of policies. To make a decision, the PDP often requires external data, which it retrieves from a Policy Information Point (PIP). An application component, the Policy Enforcement Point (PEP), requests a decision from the PDP and enforces the outcome.
Implementations like Open Policy Agent (OPA) with its Rego language or the Cedar policy language embody this pattern. Policies are managed as code, allowing for testing, versioning, and auditing. The core philosophy is to centralize authorization logic in a portable engine that can make dynamic, context-aware decisions without modifying the underlying application. This model excels at enforcing broad, organizational guardrails, such as rules based on data classification, user location, or time of day.
How ReBAC differs
Relationship-based access control grounds authorization in the connections between entities. Instead of evaluating abstract policies, a ReBAC system checks for the existence of a path in a graph of explicit relationships. This model, popularized by Google's Zanzibar paper, stores authorization data as tuples, such as document:123#editor@user:alice. The system’s schema defines the possible relationships and how they compose. For example, it might state that an editor is also a viewer, or that a user who has access to a folder implicitly has access to the documents within it.
Authorization checks become graph traversal problems. The system determines if a subject is connected to an object through a specified relation. Systems like SpiceDB and OpenFGA implement this approach. The fundamental difference from PBAC is that ReBAC stores authorization facts directly as data, whereas PBAC stores the logic for deriving those facts from external attributes. This makes ReBAC exceptionally well-suited for modeling fine-grained sharing and complex ownership hierarchies common in collaborative applications.
Performance characteristics
Each model presents a different performance profile. PBAC engines are optimized for fast, stateless policy evaluation. When the necessary attributes are provided with the request, engines like OPA can deliver decisions with near-constant time latency. Performance can degrade if the PDP must fetch data from external services during evaluation, introducing network latency and potential availability issues. Scaling often involves distributing policy bundles to local sidecar PDPs, minimizing decision latency by keeping logic close to the application.
ReBAC systems are optimized for low-latency graph queries over a large dataset of relationships. Systems inspired by Zanzibar are designed to serve millions of checks per second with single-digit millisecond latency by using aggressive caching, secondary indexes, and request hedging. A key feature is the use of consistency tokens, which ensure that access decisions reflect all preceding permission changes, preventing subtle race conditions. While simple checks are extremely fast, more complex queries like listing all accessible resources can be computationally intensive and require careful schema design.
When to choose PBAC
PBAC is the ideal choice when authorization decisions rely heavily on dynamic, contextual attributes that are not inherent to the relationships between users and resources. It excels in scenarios requiring centralized policy governance and auditability across a heterogeneous environment. For example, enforcing compliance rules that restrict access based on a user's device posture, IP address, or risk score is a classic PBAC use case. It is also well-suited for infrastructure authorization, such as Kubernetes admission control or API gateway security, where policies act as organization-wide guardrails.
When ReBAC makes sense
ReBAC is the superior model for applications where the user experience is driven by sharing, collaboration, and complex ownership. If your product features include a "Share" button, nested resources like folders and documents, or delegated permissions, ReBAC provides a natural and scalable way to model these interactions. It effectively solves problems involving multi-tenant permissions, collaborative applications, and enterprise SaaS products where users grant access to specific resources. The ability to perform "reverse lookups" to efficiently determine who can access a resource is another significant advantage.
Combining both approaches
The two models are not mutually exclusive and can be combined to leverage the strengths of each. A common hybrid pattern uses ReBAC to manage the core relationship graph—who owns what, who is in which group—while PBAC handles contextual overlays. For instance, a ReBAC check might confirm that a user is an editor of a document, but a PBAC policy could deny access if the request originates from an untrusted network.
Modern ReBAC systems facilitate this integration through features like caveats or conditions. A caveat attaches a small, attribute-based policy to a specific relationship. The system evaluates the relationship graph first and then, if a path is found, evaluates the associated caveat. This allows teams to incorporate dynamic context directly into the relationship model without sacrificing the performance and consistency benefits of ReBAC.
| Factor | Policy-Based Access Control (PBAC) | Relationship-Based Access Control (ReBAC) |
|---|---|---|
| Data location | Policies are central; attributes are external. | Centralized in a dedicated authorization service or database. |
| Performance | Fast if attributes are provided; latency from data fetches. | Latency depends on graph depth and width; relies on heavy caching. |
| Best use cases | Context-aware rules, infrastructure, central governance. | Collaboration, fine-grained sharing, resource hierarchies, enterprise apps. |
| Data structure | Policies (code) and attributes (JSON/key-value). | Graph of subjects, resources, and relationships. |
| Query types | "Can subject do action on resource with context?" | "Can subject perform action on resource?" |
| Permission changes | Modify policy code; may require new attribute sources. | Adding relationship data. Modifying the schema that defines relations and permissions. |
| Consistency | Depends on attribute source consistency. | Can utilize consistency tokens to prevent stale reads. |
| Deployment complexity | Simpler for local/sidecar models; data sourcing is key. | Requires deploying and managing a specialized authorization service. Hosted services are also available. |
FAQ
What is the primary factor for choosing one model over the other?
The most important factor is whether your authorization logic is driven by who someone is or what they can access. If your rules center on basic attribute-driven policies like role, location, or compliance requirements, PBAC is a decent starting point. If your application centers on user-to-resource relationships, sharing, or ownership hierarchies, ReBAC is better suited to modeling those interactions directly.
Can PBAC model relationships?
Yes, but it can be cumbersome. You can represent relationships as attributes of a user or resource (e.g., resource.owner_id == user.id). However, this approach does not easily handle indirect relationships, such as group membership or hierarchical permissions, which require complex logic within the policy and often lead to performance issues as the number of relationships grows.
What is the "New Enemy Problem" and how does ReBAC solve it?
The "New Enemy Problem" is a race condition where a user gains access to a resource before a permission change revoking their access has fully propagated. ReBAC systems like Zanzibar solve this with consistency tokens, ensuring that an authorization check is evaluated at a point in time that is at least as recent as any related permission changes.
How do these models handle changes to permissions?
In PBAC, changing permissions usually means updating a policy file and distributing it to the decision points. This is an operational task managed via a CI/CD pipeline. In ReBAC, changing permissions is a data operation. It involves writing or deleting relationship tuples via an API call, which is typically triggered by user actions within the application.
Are there performance limits to consider with ReBAC's graph model?
Yes, unbounded graph traversals can cause performance issues. Well-designed ReBAC schemas use userset rewrites to bound the search space and keep checks fast. Queries that ask to list all objects a user can access can also be expensive, so systems often provide specific APIs and indexing strategies to optimize these operations.