OSS fine-grained authorization based on Google Zanzibar. Apache-2.0 under Linux Foundation. Relationship-based access control (ReBAC) for hierarchical permissions, sharing semantics, and complex enterprise authorization graphs.
OpenFGA is a Linux Foundation OSS fine-grained authorization service based on Google's Zanzibar paper, providing relationship-based access control (ReBAC) that handles hierarchical permissions, sharing semantics, and complex enterprise authorization graphs that pure RBAC cannot express. It is the rare L5 component that lets agents enforce real ABAC at sub-10ms latency without locking teams into a proprietary policy language. The key tradeoff: best-in-class authorization expressiveness and performance versus an extra operational dependency that must be modeled and kept in sync with the underlying domain.
For Layer 5 authorization, trust is binary: either the policy decision matches the intended rule, or the system is unsafe. OpenFGA's ReBAC model lets you express the rules that agents actually need — 'this agent can read this document because the requesting user is a viewer of the folder that contains it' — which is exactly the kind of derived permission that RBAC mangles. The strongest trust property is what OpenFGA prevents: agents asking permission questions that are answered by the application's own code path instead of a central policy engine. Misconfiguration is still the dominant risk, and the auth model file becomes a critical artifact that needs the same review discipline as schema migrations.
Sub-10ms p99 authorization checks on the reference deployment per the OpenFGA performance docs; designed from day one for hot-path enforcement. Easily handles agent-scale check volumes (thousands of checks per agent turn).
DSL is purpose-built and small enough to learn in an afternoon. Playground, modeling guides, and code samples are strong. The model file (`.fga`) is the single source of truth; standard SQL-like familiarity does not transfer but the alternative is the Zanzibar paper which is harder.
This is OpenFGA's core competence: full ABAC / ReBAC with contextual tuples, conditions, and computed relationships. Far exceeds the RBAC cap rule — exists to make P=6 achievable for the stacks that adopt it.
OSS Apache-2.0 under Linux Foundation governance, self-hostable everywhere. SDKs for Go, Node.js, Python, Java, .NET, Ruby. Auth0 FGA offers a managed deployment. Backed by Postgres or MySQL — both cloud-portable.
Authorization model file expresses domain relationships explicitly — readers of the model file can understand the access semantics without reading application code. Contextual tuples allow request-time context to flow into decisions.
OSS code, structured decision logs (Check / ListObjects / Write events), and a deterministic decision model make it auditable. Lacks built-in cost attribution per query in the OSS edition; managed offerings add usage analytics.
Authorization is a core governance primitive and OpenFGA centralizes it. Model file is version-controlled; tuples are auditable; decisions are loggable. The single biggest governance lift on the L5 axis a stack can make.
Exposes Prometheus metrics, OpenTelemetry traces, and structured decision logs. Managed offerings add dashboards. OSS observability is solid but the L5-specific question 'why did this check fail' still requires log spelunking.
Stateless service backed by Postgres / MySQL; HA via standard database replication. Auth0 FGA managed offering has enterprise SLAs. Self-hosted HA requires the usual database HA discipline.
Authorization model is itself a domain vocabulary — `document`, `folder`, `viewer`, `editor` are first-class types. Strong semantic primitives that map cleanly to the way the business talks about access.
Linux Foundation project (donated by Auth0 / Okta), CNCF Sandbox in 2022, broad adoption across enterprise stacks. Production stable but the ecosystem is younger than legacy IAM tooling.
Best suited for
Compliance certifications
OSS Apache-2.0; no first-party FedRAMP, HIPAA BAA, or SOC2 on the OSS edition. Auth0 FGA managed offering inherits Auth0's compliance posture — verify with the vendor for current certifications.
Use with caution for
Both are Zanzibar-derived OSS ReBAC engines. SpiceDB is more mature in enterprise deployments and offers a richer schema language; OpenFGA has stronger ecosystem momentum since the Linux Foundation move and a simpler initial learning curve. Either is a defensible choice — pick on team familiarity and managed-offering preference.
View analysis →Role: Sits at Layer 5 as the central authorization decision point — the single place every read and write asks 'is this allowed' before touching L1 or L4 resources.
Upstream: Authorization model file (`.fga`) deployed alongside application code; tuples written from application services in lockstep with domain mutations (transaction or outbox).
Downstream: Application services, AI agents, and gateways call Check / ListObjects / BatchCheck APIs at the hot path; decision logs feed L6 telemetry and audit pipelines.
Mitigation: Treat tuple writes as part of the same transaction or outbox as domain mutations; add a periodic reconciliation job; alert on tuple counts diverging from expected ratios
Mitigation: Use OpenFGA's model versioning; deploy model changes as migrations with explicit tuple backfill steps; canary new models against a sample of production checks before cutover
Mitigation: Adopt a 'no permission check, no response' lint rule in code review; track per-endpoint check counts and alert on endpoints that stop checking
ReBAC with relationships like `viewer_of` on a folder is exactly the shape of this problem. OpenFGA's check latency keeps the agent's per-resource gating cheap.
ABAC with contextual tuples (current shift, care-team membership, attending physician) is precisely what OpenFGA is built for — self-host in a HIPAA-eligible environment.
The modeling overhead outweighs the benefit. A simple RBAC table or Auth0 / Cognito roles will do the job at lower operational cost.
This analysis is AI-generated using the INPACT and GOALS frameworks from "Trust Before Intelligence." Scores and assessments are algorithmic and may not reflect the vendor's complete capabilities. Always validate with your own evaluation.