A relationship graph represents entities as nodes and their connections as edges. In authorization, the entities may be employees, customers, teams, documents, tickets, and folders; the edges express facts such as ownership, membership, viewer access, management, or customer support. Access can then depend on who is connected to a resource and how, rather than only on a centrally assigned role or a set of attributes. section 6.1 section 9.4
Sharing a customer support ticket
A support engineer can be an editor of a ticket, a customer can be its viewer, and a manager can gain access through the engineer or owner. A rule can grant viewing to a viewer or owner, updating to an editor, and broader access to an owner; another can recognize a manager of the owner. The graph supplies the current relationship facts while the rules remain stable. section 6.1.1 section 6.3.1
Figure 6.1 A relationship graph used by ACME Corp’s Customer Collaboration platform. Employees like Bob and Alice are linked to customer accounts through roles such as support engineer and solution architect. Access to resources such as support tickets and deployment plans is controlled by these relationships, allowing for dynamic, fine-grained authorization decisions based on who is connected to what and how.
Inspect a collaboration graph in which employee and customer relationships determine access to tickets and deployment plans. section 6.1
Relationship-based access control (ReBAC) uses the graph as authorization data. A request reaches an authorization service, which evaluates static rules against the graph’s current state. Changing an owner, team assignment, or sharing relationship changes later decisions without editing policy code. This fits collaborative systems where delegation, ownership, and organizational connections change often. section 6.1.1 section 6.1.2
A relationship graph supports several authorization responsibilities:
- Model direct and indirect access paths, such as viewer, owner, editor, or manager of an owner. section 6.1.1
- Delegate policy administration through contextual actions such as sharing a document or assigning a teammate, because those actions update relationship data. section 6.1.2
- Provide a central, queryable entity store for policy evaluation, auditing, and debugging rather than scatter relationship checks through applications. section 6.1.2 section 9.4
- Represent changing organizational data—such as membership, ownership, transfers, and customer rosters—as graph updates while retaining static policy logic. section 9.4
OpenFGA stores graph facts as tuples and evaluates permissions by traversing typed relationships under a schema. A tuple such as document:123#viewer@user:alice records one relationship fact. Types define valid entities, relations define named links, and permissions combine relations into checks such as viewing or editing. This approach is designed for relationship logic rather than request attributes or conditional rules. section 8.3 section 8.3.1
Combining relationship and context checks
A relationship graph can establish that a person owns a document, belongs to a team, or manages an owner. It should not be overloaded with transient conditions such as time of day, device posture, location, or risk. Attribute-based access control (ABAC) or external application logic can handle those conditions alongside relationship-based decisions. section 6.1.5 section 9.10
Graphs need operational discipline. Dense or large graphs can obscure why access was granted and make a small relationship change consequential. Effective use requires clear relationship modeling, lifecycle management, path tracing, auditing, guardrails, training, and simulation tooling. ReBAC is strongest when durable collaboration relationships are the real basis for access; it is weaker when runtime context or complex conditional business logic dominates. section 6.1.3 section 6.1.5
