OpenFGA is an open-source authorization system for relationship-based access control (ReBAC). It fits products where access follows ownership, sharing, delegation, team membership, or collaboration rather than a static role alone. Instead of embedding authorization logic in application code, it models users, resources, groups, and roles as connected data, then answers permission checks by traversing those relationships. section 8.3 section 8.5.3
Its policy model has two parts. A declarative schema defines typed entities such as users, documents, and folders; it also defines relations, such as owner, viewer, and editor, plus named permissions expressed as logical combinations of relations. Relationship tuples then record individual facts. Together, the schema and tuples form a directed relationship graph used to decide whether a requested permission holds. section 8.3.1
Checking document access
A tuple such as `document:123#viewer@user:alice` states that Alice is a viewer of Document 123. For a request such as “Can Alice view Document 123?”, OpenFGA applies the document schema and walks the graph to determine whether `can_view` is satisfied. Permissions can combine direct relationships and derived relationships, allowing sharing and delegation to change access dynamically. section 8.3.1 section 8.3.3
document:123#viewer@user:alice
This tuple is the basic stored relationship fact: a typed document has a viewer relation to a typed user. section 8.3.1
OpenFGA makes several architectural trade-offs:
- It treats principals as entities present in relationships, not as profiles carrying native attributes. section 8.3.3
- It represents actions as schema-defined named permissions such as `can_view` or `can_edit`, rather than conventional action values evaluated at runtime. section 8.3.3
- It provides no native evaluation of time, location, device posture, or risk score; applications or middleware must handle such context externally and may encode the outcome as a relationship. section 8.3.3
- It is strong for delegable sharing and relationship-rich access, but may need another system when fine-grained attribute-based or contextual decisions are required. section 8.5.3
Choose OpenFGA when the central authorization question is who is connected to a resource and through which relationships. This is especially useful for customer collaboration systems with employees, external partners, shared documents, comments, and delegated responsibilities. When runtime context is essential, pair its relationship decisions with external application logic or another authorization capability. section 8.0 section 8.5.6
