OpenFGA (Fine-Grained Authorization)
OpenFGA is an open-source fine-grained authorization engine (Google Zanzibar-inspired, by Okta) that evaluates relationship-based access control (ReBAC) via a tuple model — agents write (user, relation, object) tuples and call the Check API to determine if a user has a specific permission on a specific resource.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
OpenFGA's relationship tuple model provides the highest granularity of any authorization approach — every permission is explicit. Backed by Okta with regular security reviews. Self-hosted deployments must secure the admin API (no auth by default in dev mode).
⚡ Reliability
Best When
You need resource-level, relationship-based authorization (like Google Drive sharing: 'Alice can edit document 42 because she's a member of team 7 which has editor access to folder 3') that cannot be expressed in simple roles.
Avoid When
Your authorization model is simple enough to express as flat roles in a JWT claim — OpenFGA adds operational complexity (running a separate service, managing tuple storage) that is not justified for simple use cases.
Use Cases
- • Check whether a user has 'editor' access to a specific document by calling the Check API with a (user:alice, relation:editor, object:document:123) tuple — in under 10ms for cached results
- • Define a hierarchical authorization model (organization → workspace → project → document) using the OpenFGA DSL and let the engine traverse the relationship graph automatically
- • Perform batch authorization checks via the BatchCheck API to evaluate multiple (user, relation, object) combinations in a single request — useful for filtering UI elements or search results
- • Write relationship tuples programmatically when users are added to roles, teams, or resource ACLs — and delete tuples when access is revoked — keeping the authorization state synchronized
- • Use the ListObjects API to answer 'what documents can user:alice view?' without scanning every document — the engine traverses the relationship graph and returns all matching objects
Not For
- • Authentication — OpenFGA only answers authorization questions (can user X do Y to Z?); it has no concept of identity verification, sessions, or login flows
- • Simple flat RBAC with 3-5 roles and no resource-level permissions — OpenFGA's tuple model is overkill; a simple role check in your application code or a basic RBAC library suffices
- • Real-time streaming permission changes with sub-millisecond latency — OpenFGA uses eventual consistency for tuple propagation; there is a brief window after writes where reads may return stale results
Interface
Authentication
OpenFGA supports no-auth (development), pre-shared API key, and OIDC Client Credentials auth modes. The auth method is configured at server startup. Okta FGA (managed) uses API key auth.
Pricing
Self-hosted OpenFGA is free and unlimited. Okta FGA is the managed cloud offering with a generous free tier and consumption-based pricing above that.
Agent Metadata
Known Gotchas
- ⚠ Authorization model versioning: each Write of a new model creates a new model ID; the Check API uses the latest model by default but existing tuples are not migrated — agents that update the model must verify all existing tuples are still valid under the new schema
- ⚠ Eventual consistency: tuple writes are asynchronous in clustered deployments; a Check immediately after a Write may return the old result — build retry logic with a short delay (100-500ms) for latency-sensitive authorization gates
- ⚠ The Check API returns {allowed: false} for any error condition including invalid store ID, invalid model, or missing tuple — agents must separately verify that a false result is an authorization denial and not a configuration error by checking the HTTP status code
- ⚠ Tuple fan-out limits: deeply nested relationship graphs (e.g., user → member_of → group → member_of → group → ... → has_access → document) can cause expensive recursive checks; OpenFGA enforces a default max depth of 25 hops — model complex permissions as direct tuples to avoid timeouts
- ⚠ Store isolation: each OpenFGA store is completely isolated (no cross-store lookups); agents managing multi-tenant systems must decide between one store per tenant (isolated but high operational overhead) or shared store with tenant-prefixed object IDs (efficient but requires careful model design)
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for OpenFGA (Fine-Grained Authorization).
Scores are editorial opinions as of 2026-03-06.