Loading
Loading
3366 Members
Join Permit's SlackAuthorization has come a long way from simple role checks and hard-coded logic. As systems grow more collaborative and data becomes more interconnected, Relationship-Based Access Control (ReBAC) has become a leading pattern for managing permissions.
In this blog, we’ll compare two of the most popular implementations of ReBAC today: OpenFGA and Permit.io, and see how they differ in approach, developer experience, and real-world usability.
ReBAC (Relationship-Based Access Control) defines permissions based on the relationships between entities, users, groups, organizations, and resources, rather than fixed roles.
For example:
“A user can view a document if they own it, are a member of a group that owns the folder, or belong to the organization that manages it.”
This relationship-driven model is essential for platforms where hierarchies, inheritance, and dynamic sharing dominate access decisions, like SaaS collaboration tools, multi-tenant systems, or enterprise resource managers.
At its core, ReBAC represents authorization as a graph, allowing you to query how entities relate instead of re-implementing nested permission checks in every service.
OpenFGA, originally developed at Okta and now a CNCF project, implements the Zanzibar model as a self-hosted service. Developers define an authorization model using a DSL and store relationship tuples in a database.
Example model:
type document
relations
define viewer: [user, group]
define can_view: viewer
A tuple might look like:
user:carla is viewer of document:planning
To check access, the application sends a query to the OpenFGA API:
curl -X POST $FGA_URL/check \\
-d '{"user":"user:carla","relation":"can_view","object":"document:planning"}'
OpenFGA gives you fine-grained control, but you operate and scale it yourself.
Permit.io builds on the same ReBAC principles as Zanzibar but focuses on developer velocity and operational simplicity.
Instead of managing a ReBAC database and writing your own admin UIs, Permit.io offers a managed authorization service with SDKs, APIs, Terraform support, and a no-code Policy Editor UI.
Developers define resources, roles, and relations as code, then extend them with attributes for ABAC-style conditions.
Example (Terraform):
resource "permitio_role_derivation" "folder_viewer_to_doc_viewer" {
resource = permitio_resource.document.key
role = permitio_role.doc_viewer.key
on_resource = permitio_resource.folder.key
to_role = permitio_role.folder_viewer.key
linked_by = "parent"
}
With this setup, a user who can view a folder automatically inherits view access to all documents within it, so no extra checks or manual propagation are needed.
Permit.io provides developers with a permission management solution that allows smooth transitioning between RBAC, ABAC, and ReBAC all without changing your application code.
The Permit Policy Editor makes this possible with a no-code UI that automatically generates Rego policies for all three models and syncs them seamlessly with your Git, API, and UI interfaces.
This means both developers and non-technical stakeholders can create and manage ReBAC policies, build complex graph hierarchies, and define relationships between entities all visually, without writing a single line of code.
In the editor, relations (graph edges) can be created between resources (graph nodes) with just a few clicks, offering an intuitive, low-code experience for defining access logic.
Try the Permit.io Policy Editor
Permit.io extends ReBAC beyond relationships into a complete authorization platform for modern apps.
| Aspect | Permit.io | OpenFGA |
|---|---|---|
| Deployment | Managed SaaS | Self-hosted |
| Model Type | ReBAC + ABAC | ReBAC only |
| Policy Editor (UI) | Yes | No |
| Terraform Integration | Yes | Limited |
| Cedar Compatibility | (via Cedar-Agent) | No |
| Infra Maintenance | None | Requires ops |
| Versioning & Audit | Built-in | Manual |
| Best for | Product & platform teams | Infra-heavy teams |
Summary: OpenFGA offers the core ReBAC engine; Permit.io adds the tooling, UI, and hybrid capabilities that make it production-ready.
OpenFGA is stateful and centralized, requiring developers to maintain a database of relationship tuples and scale it to handle authorization queries. While fast, its performance depends on how well you tune your storage and cache layers.
Permit.io operates as a managed service with global distribution, automatic caching, and real-time policy updates. No synchronization scripts or ops overhead are needed.
Permit.io can evaluate hybrid (ReBAC + ABAC) policies in a single decision API call, which is useful for complex systems where relationships and attributes matter. That is the practical upside of combining policy as code and policy as graph in one system.
For teams with very large relationship graphs, we built Nexus PDP (early access). It runs next to your service, so the decision path has no remote network hop. In its published beta benchmark, one 2 CPU pod answered RBAC checks at 5.6 ms P99 and ReBAC checks three hops deep at under 11.3 ms P99, measured server-side. That puts it in the same range as OpenFGA and AuthZed, and can be faster depending on topology and workload, without a tuple database for you to run and tune.
Choose OpenFGA if:
Choose Permit.io if:
Permit.io lets developers ship authorization as code and as a service.
In short, OpenFGA gives you the engine. Permit.io gives you the entire platform.
Co-Founder / CEO at Permit.io
