ReBAC in practice: what OpenFGA and Permit.io change

At a glance

What this is: This is a comparison of two ReBAC implementations, showing how graph-based authorisation changes permissions management for collaborative systems.

Why it matters: It matters because IAM, PAM, and application security teams need governance patterns that can handle relationship-driven access without losing control, auditability, or lifecycle discipline.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Permit.io's comparison of ReBAC implementations in production systems

Context

Relationship-Based Access Control, or ReBAC, shifts authorisation from fixed role checks to relationship-aware decisions. That matters in systems where access depends on ownership, tenancy, parent-child resources, and other graph-like relationships, because hard-coded permission logic becomes brittle as applications grow.

For IAM and application security teams, the real issue is not whether ReBAC can express complex access rules. It is whether those rules remain governable once they span developer code, infrastructure, policy editors, and audit requirements across human and non-human identities. That is the operating problem this comparison surfaces.

The article is a practical comparison of two ReBAC implementations, not a theory paper. The typical challenge it describes is common in modern platforms: the control model is powerful, but operational ownership, lifecycle management, and policy drift become the real differentiators.

Key questions

Q: How should security teams govern relationship-based access control at scale?

A: Treat ReBAC as a governed identity system, not just an application pattern. Security teams should define ownership for relationship data, review inheritance paths regularly, and require audit trails for every tuple or policy change. Without that discipline, graph permissions can expand silently and make least privilege difficult to prove.

Q: When does ReBAC create more risk than it reduces?

A: ReBAC becomes risky when the relationship graph is stale, poorly synchronised, or spread across teams without a single ownership model. In that state, the policy is expressive but the control is unreliable. The risk is not the model itself, but the inability to keep graph state accurate enough for trustworthy decisions.

Q: What do teams get wrong about hybrid RBAC, ABAC, and ReBAC models?

A: Teams often assume more policy dimensions automatically mean better security. In practice, every added attribute or relationship rule increases explanation and testing burden. The safer approach is to use ReBAC for structural inheritance, then add ABAC only where context genuinely changes the access decision.

Q: How should organisations choose between self-hosted and managed authorisation?

A: Choose based on operational maturity, not ideology. If your team can reliably run databases, caches, policy APIs, and audit workflows, self-hosting may fit. If not, managed authorisation reduces infrastructure burden and can improve governance visibility, but you still need clear ownership for policy design and review.

Technical breakdown

ReBAC authorization graphs and tuple checks

ReBAC models permissions as relationships between subjects, groups, resources, and organisations. Instead of asking whether a user has a role, the system asks whether a path exists in the relationship graph that satisfies the policy. This usually means storing relationship tuples and evaluating queries such as viewer, parent, or member at request time. The strength is expressive inheritance. The weakness is that graph accuracy becomes part of your security boundary, so stale tuples or missing sync logic can produce incorrect decisions even when the policy language itself is sound.

Practical implication: treat the relationship store as a governed security system, not just an application data layer.

Managed authorization versus self-hosted ReBAC

The article contrasts a managed authorization service with a self-hosted ReBAC engine. That difference is operational as much as architectural. A managed service abstracts infrastructure, scaling, audit features, and policy tooling into one control plane, while a self-hosted engine leaves the team responsible for storage, caching, uptime, and policy administration. For security teams, the key architectural question is where authorisation state lives, who can change it, and how quickly changes propagate across services that depend on it.

Practical implication: decide whether your team is prepared to own policy infrastructure, not just policy definitions.

Hybrid RBAC, ABAC, and ReBAC policy evaluation

The article also shows how ReBAC often stops being sufficient on its own once real-world conditions enter the picture. In practice, relationships define baseline access, but attributes such as tenant state, resource sensitivity, or deployment context may also shape the decision. That is why hybrid models matter: they avoid exploding the number of graph edges or role variants just to express context. The trade-off is governance complexity, because the more policy dimensions you combine, the harder it becomes to explain and recertify why access was allowed.

Practical implication: add attribute conditions only where relationship checks alone cannot carry the access decision.

NHI Mgmt Group analysis

ReBAC becomes a governance problem the moment it leaves the diagram. Relationship graphs are attractive because they match how modern applications actually share data, but they also move authorisation control into a stateful model that must be curated continuously. Once graph edges, tuples, and inheritance rules become operational security artefacts, lifecycle discipline matters as much as policy design. The implication is that teams must govern who can mutate the graph, not just who can query it.

Managed authorisation is really a control-plane decision. The important difference is not only developer convenience, but how much of the authorisation lifecycle the platform absorbs. Versioning, auditability, and policy rollout become security controls, not admin features. That makes this pattern attractive for teams that need governance visibility across engineering and security, especially where human access decisions and machine-driven access checks coexist.

OpenFGA-style self-hosting preserves control, but it also preserves operational responsibility. When you own the database, API, and cache, you also own the consistency, latency, and failure modes that determine whether authorisation is trustworthy in production. That is a meaningful governance trade-off for teams with strong platform engineering maturity. The practitioner conclusion is simple: if you cannot reliably operate policy state, you have not really outsourced the complexity.

Hybrid RBAC plus ABAC plus ReBAC is the likely destination for complex enterprises, not a niche enhancement. Pure relationship logic handles hierarchy well, but real authorisation also depends on context, sensitivity, and operational conditions. The deeper point is that every additional policy dimension increases explainability demands for IAM, audit, and application owners. Teams should expect the governance burden to rise as access logic gets more accurate.

Graph-based access control creates a new kind of identity blast radius. When a single relationship edge can unlock access across many descendants, a small policy mistake can propagate far beyond its original scope. That is why relationship management belongs in the same conversation as least privilege, recertification, and privileged access governance. Practitioners should evaluate ReBAC through impact radius, not just expressiveness.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows why relationship-driven access decisions need stronger governance than most teams currently have.
• That visibility gap is one reason to revisit NHI Lifecycle Management Guide alongside ReBAC design, especially where access inheritance outlives ownership changes.

What this signals

Identity blast radius is the right way to think about ReBAC in production: a single inherited edge can unlock broad downstream access if ownership and revocation are not tightly governed. Teams should evaluate relationship-based policies by how far one mistaken link can propagate, not only by how elegantly the policy reads.

The practical implication for IAM programmes is that policy expressiveness is no substitute for lifecycle control. If relationship tuples are not versioned, recertified, and revoked with the same discipline as privileged accounts, the access graph becomes a hidden privilege store.

For teams building modern authorisation layers, the question is whether the programme can explain every effective permission in audit terms. That is where the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 become useful references, because they force governance back onto accountability, visibility, and control ownership.

For practitioners

• Inventory relationship sources and update paths Map every system that creates or syncs relationship tuples, then define who approves changes and how stale edges are removed when ownership changes.
• Separate policy logic from application code Keep access rules in a governed policy layer so developers are not re-implementing nested checks in multiple services and teams can review the same source of truth.
• Recertify descendant access paths Review inherited permissions for folders, tenants, and org structures on a fixed schedule so access granted through parent relationships does not outlive the business need.
• Track policy change auditability end to end Ensure every relationship edit, role derivation, and attribute condition produces a durable audit record that can be traced back to an accountable owner.

Key takeaways

• ReBAC solves a real authorisation problem, but it shifts security attention from roles to relationship state and inheritance.
• The operational question is not whether the model is expressive enough, but whether teams can govern tuple accuracy, auditability, and lifecycle change.
• Any ReBAC deployment should be evaluated for identity blast radius, because one incorrect edge can expand access far beyond its intended scope.

Key terms

• Relationship-Based Access Control: A permission model that grants access based on the relationships between identities, groups, organisations, and resources. In practice, ReBAC turns authorisation into graph evaluation, which is powerful for shared and hierarchical systems but only safe when relationship data is accurate and continuously governed.
• Authorization Graph: The data structure used to represent who can access what through connected entities and edges. It makes inherited and contextual access easier to express, but it also creates a new governance surface because stale links or missing updates can expand access silently.
• Inherited Access: Access that flows from a parent relationship to child objects, such as a folder granting rights to its documents. It reduces policy duplication, but in production it also increases blast radius, because one upstream change can affect many downstream resources at once.
• Authorization as Code: The practice of managing access logic through versioned code, infrastructure definitions, or policy files. It improves change control and reviewability, but it only delivers security value when the surrounding policy lifecycle, testing, and audit processes are equally disciplined.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.

This post draws on content published by Permit.io: ReBAC in Practice, comparing Permit.io and OpenFGA. Read the original.