Attribute-based access control (ABAC) and relationship-based access control (ReBAC) represent two distinct philosophies for managing authorization. ABAC evaluates policies against a collection of attributes, while ReBAC computes permissions by traversing a graph of stored relationships between entities. Understanding their core mechanics, performance characteristics, and ideal use cases is essential for architects choosing how to secure modern applications. This summary explores these differences to guide decisions on which model, or combination of models, best fits a given problem.
What ABAC does
Attribute-based access control makes authorization decisions by evaluating policies that reference attributes of a subject, a resource, an action, and the environment. Its core philosophy, formalized in standards like NIST SP 800-162, is to decouple authorization logic from application code. In a typical ABAC architecture, a Policy Enforcement Point (PEP) intercepts an action and queries a Policy Decision Point (PDP). The PDP evaluates a set of policies against the attributes of the request. If the policies require additional information, a Policy Information Point (PIP) can fetch attributes from external sources like an identity provider or a database. This model allows for dynamic, context-aware decisions. Policies written in languages like Rego, Cedar, or the traditional XACML can enforce rules such as "allow access only if the user's department attribute matches the resource's department tag and the request occurs during business hours."
How ReBAC differs
Relationship-based access control centers on the idea that permissions are a function of the relationships between entities. Instead of evaluating transient attributes against a policy, ReBAC stores authorization data as a set of explicit facts, or tuples, in a dedicated datastore. These tuples, such as document:report.docx#viewer@user:alice, form a directed graph of relationships. An authorization check becomes a graph traversal problem: can a path be found from the subject to the resource via a specific permission? This approach was operationalized at scale in Google's Zanzibar system. The fundamental architectural divergence from ABAC is that ReBAC treats authorization data as a first-class, centrally managed dataset, rather than dynamically sourced attributes. Permissions are derived directly from this graph, defined in a schema that specifies how relationships compose, such as an editor also being a viewer.
Performance characteristics
ReBAC systems are designed for predictable, low-latency authorization checks at a very large scale. Implementations like Zanzibar achieve p95 latencies under 10 milliseconds for trillions of relationships by using specialized data structures and indexes. They also provide strong consistency guarantees using mechanisms like "zookies" to prevent stale reads, which mitigates problems like a user accessing a resource they were just removed from. The performance of ReBAC is primarily influenced by the depth and complexity of the relationship graph.
ABAC performance, in contrast, depends on two main factors: the complexity of the policy evaluation and the latency of attribute retrieval. While evaluating policies within a PDP is typically fast, fetching attributes from external PIPs can introduce significant and unpredictable latency. Scaling ABAC involves replicating PDPs and caching attributes, but consistency can be a challenge if attributes are sourced from different systems that update on different schedules.
When to choose ABAC
ABAC is the ideal choice when authorization decisions must be sensitive to dynamic context. It excels in scenarios where rules depend on attributes that are not part of a resource's direct relationships, such as the time of day, the user's geographic location, or the security posture of their device. A primary use case is tag-based governance in cloud infrastructure, where policies grant access based on matching tags on principals and resources. This allows for broad, attribute-driven rules that do not require enumerating specific resource identifiers, making it effective for managing large, ephemeral environments.
When ReBAC makes sense
ReBAC provides clear advantages for applications with features built around sharing, delegation, and complex hierarchies. It is a natural fit for collaborative software like document editors or project management tools, where users grant permissions on individual resources to other users or teams. The model elegantly handles inheritance, such as a user gaining access to a document because they have access to its parent folder. Its ability to efficiently query and explain fine-grained permissions makes it well-suited for applications that require a "who has access" or "share" user experience, especially in multi-tenant architectures.
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-based permissions and supplements it with ABAC for contextual checks. Modern ReBAC systems facilitate this through features like caveats in SpiceDB or conditional tuples in OpenFGA. These features allow a ABAC-style policy to be attached to a specific relationship. For example, a ReBAC relationship might grant a user editor access, but a caveat could enforce that this access is only valid from a corporate IP address. This hybrid approach keeps the graph model clean while accommodating dynamic, risk-based policy requirements.
Comparison table
| Factor | Relationship-Based Access Control (ReBAC) | Attribute-Based Access Control (ABAC) |
|---|---|---|
| Data location | Relationship tuples live in a centralized graph-oriented authorization store (single system of record for who is related to what). | Policies and decisions depend on attributes that may be spread across a PDP, PIPs, IdPs, and other data stores. |
| Performance | Tuned for fast, predictable permission checks; latency driven mainly by graph depth/breadth and indexing (see body for scale/consistency patterns). | Policy evaluation is often fast, but total latency can vary with attribute fetch latency from external systems. |
| Best use cases | Fine-grained sharing, delegation, hierarchies, and “who has access to this resource?” product flows; strong fit for collaborative and multi-tenant apps. | Highly contextual rules (time, location, device posture, tags), broad cloud/resource governance, and attribute-heavy policies without encoding every relationship as graph data. |
| Query types | Graph-style questions: check/traverse relationships (e.g. Check, Expand, List-style APIs in Zanzibar-inspired systems). | Policy evaluation: does this subject/resource/action/environment satisfy the policy given current attributes? |
| Permission changes | Write relationship tuples; evolve schema for how relations compose; data migration when relationship shapes change. | Change policies and/or attribute definitions; coordinate updates across systems that supply attributes. |
| Consistency | Zanzibar-style designs often emphasize snapshot or consistency-token semantics so checks don’t read arbitrarily stale relationship state. | Consistency is as strong as attribute freshness across PIPs and caches; heterogeneous sources can make uniform guarantees harder. |
| Deployment complexity | Operate and scale a dedicated relationship store and ingestion path for tuples. | Integrate PDP with policies and reliably source attributes from many systems (PIPs, caches, governance of attribute quality). |
FAQ
Can ABAC be used to model relationships?
Yes, it is possible to model relationships using attributes, for example by assigning a resource an owner_id attribute. However, this becomes inefficient and complex when modeling indirect access, such as through group memberships or hierarchies, which often requires complex policies or fetching large amounts of data. ReBAC is purpose-built to handle these graph-based scenarios efficiently.
What is the primary operational challenge for each model?
For ReBAC, the main challenge is managing the lifecycle and correctness of the stored relationship data, as it is the source of truth for authorization. For ABAC, the challenge shifts to ensuring the quality, availability, and integrity of attributes sourced from distributed systems, as inaccurate or stale attributes lead to incorrect authorization decisions.
How does ReBAC provide better explainability?
Modern ReBAC systems provide APIs that can "expand" a permission to show the exact chain of relationships that grants a user access. This makes it possible to answer "why does this user have access?" with a precise, auditable path through the graph, which is often difficult in ABAC systems where the decision depends on a combination of transient attributes.
What is a "caveat" or "conditional tuple" in a ReBAC system?
A caveat is a mechanism for attaching a small, stateless condition to a relationship in a ReBAC system. It bridges the gap with ABAC by allowing a relationship to be conditional on contextual data, like an IP address or a timestamp, that is provided at the time of the authorization check. You can learn more about them in the SpiceDB documentation.
Are ReBAC systems eventually consistent?
While some graph databases are eventually consistent, systems designed for authorization like Google Zanzibar and its open source implementations prioritize consistency. They use mechanisms like zookies to ensure that authorization checks are performed at a specific point in time, preventing inconsistent or stale results that could lead to security vulnerabilities.