DEV Community

Cover image for Fine-Grained Authorization in 2026: OpenFGA, SpiceDB, Cerbos and Cedar Compared
Moksh Gupta
Moksh Gupta

Posted on Originally published at devtoollab.com

Fine-Grained Authorization in 2026: OpenFGA, SpiceDB, Cerbos and Cedar Compared

#webdev #programming #security #devops

The role column works. It works for a year, sometimes two. Then a customer wants their contractor to open one folder without seeing the invoices inside it, and separately somebody notices that a manager has been approving their own expense reports. Neither of those is a column, and that is the moment you go looking at authorization engines.

I benchmarked and priced this whole category on August 21, 2026 and put the long version on DevToolLab: Best Authorization and Permissions Tools in 2026. Condensed version follows.

Authorization and permissions tools compared

Two numbers that tell you where the category is

Amazon Verified Permissions prices a single authorization request at $0.000005. Five millionths of a dollar is an absurd unit until you notice that a real page render fires the authorization question a few thousand times, at which point the unit makes perfect sense.

Second: Cerbos meters "monthly active principals," and its pricing page explicitly defines a principal as a user or a service, bot, or other non-human identity. So 3,000 humans and 15 machine identities bills as 3,015. The vendors finished pricing for agents before most of us finished planning for them.

The lineup

Tool Shape Stars License Hosted pricing
OpenFGA Relationship 5,637 Apache 2.0 Via Auth0 FGA
SpiceDB Relationship 6,978 Apache 2.0 From $2/hr (AuthZed Cloud)
Ory Keto Relationship 5,388 Apache 2.0 Ory Network
Cerbos Policy 4,547 Apache 2.0 PoC $0, Development from $25/mo
OPA Policy 12,130 Apache 2.0 Self-hosted
Cedar Policy 1,679 Apache 2.0 $0.000005/request via AVP
Permit.io Control plane 5,501 (OPAL) Apache 2.0 (OPAL) Startup from $5/mo, Pro from $25/mo
Apache Casbin Library 20,334 Apache 2.0 None, embedded
Oso Control plane 3,492 Apache 2.0 Contact sales

Star counts read from each repository on August 21, 2026.

Relationship or policy: pick this before you pick a vendor

Getting the architecture wrong costs you far more than picking the second-best tool inside the right architecture.

Relationship engines trace back to Google's Zanzibar paper. You write tuples into the engine's own database (user:anna is member of team:platform), describe how one relation implies another, and let the engine walk the graph. Sharing hierarchies and "list everything this user can see" are its home turf, precisely because it owns the data. The bill for that: permission state now lives outside your primary database and has to stay in sync every time your app creates something shareable.

Policy engines hold no state at all. Policy is code, a decision point runs next to your service, and each request carries the principal, the resource and whatever attributes matter. Microseconds, no database round trip, policies reviewed in Git. In exchange, assembling the context is your job, and "which rows can this user see" goes back to being a query you write yourself.

The hybrids (Permit.io, Oso Cloud, WorkOS FGA) sit on top of one of those two and sell you the control plane.

Relationship engines

OpenFGA homepage

OpenFGA started at Auth0 and reached CNCF Incubating maturity on October 28, 2025, three years after being accepted. That line carries weight in an architecture review. The modeling language reads almost like English and ListObjects is a first-class operation rather than an afterthought. The real cost is operational: a stateful service, plus a write path that has to create a tuple every time your application creates a shareable resource. Nothing in the system stops you from forgetting one.

AuthZed pricing showing AuthZed Cloud from $2/hr and free self-hosted SpiceDB

SpiceDB from AuthZed is the most battle-tested Zanzibar implementation, and consistency control is what sets it apart. A permission you revoked a millisecond ago might still be sitting in a cache, so SpiceDB gives you explicit consistency levels, up to a ZedToken that guarantees a read at least as fresh as your last write. Pricing keys off deployment: open source is free, AuthZed Cloud is pitched as "deploy a permissions system for $2/hr" with $700 of starter credits, and self-hosted enterprise is licensed per region and per vCPU. It is also the biggest operational commitment on this list.

Ory Keto makes sense mostly if Kratos and Hydra are already running in your stack.

Policy engines

Cerbos pricing with a free-forever open-source PDP

Cerbos makes the opposite bet: your data never moves and the engine stores no permissions whatsoever. Run the PDP as a sidecar, keep policies as YAML in Git, ship attributes with each check. The open-source PDP is free forever; Cerbos Hub layers a control plane on top, with a Proof of Concept tier at $0/mo up to 100 monthly active principals and Development starting at $25/mo. Conditional logic is where this shape shines. Listing is its soft spot, and you reach for the query-planner API to turn a policy into a database filter.

Amazon Verified Permissions request pricing

Cedar is the language AWS open-sourced and then wrapped in a managed service. It was designed for formal analysis, which means you can reason about whether two policies conflict instead of discovering it from a support ticket. The pricing is the most legible in the category: $0.000005 per single authorization call, and batch calls billed per call no matter how many decisions ride inside, at $0.00015 for the first 40 million per month, $0.000075 for the next 60 million, $0.00004 after that. The obvious implication: fold the 50 checks a page needs into one batch call.

OPA, at 12,130 stars, is the policy engine most likely already running somewhere in your infrastructure, though usually for infra policy rather than application authorization. Stretching it to cover app authz saves you a second engine to operate. If you are not already running it, Cerbos or Cedar get you to a working decision faster.

Control planes and one library

Permit.io pricing tiers

Permit.io is the most complete control plane here, and its numbers only appear after you flip the "Show all plans" toggle: Community free forever, Startup from $5/mo (25,000 MAU, 100 tenants), Pro from $25/mo (50,000 MAU, 20,000 tenants), Enterprise unlimited. Open-source projects get Startup at no cost. Permit also maintains OPAL, the policy and data sync layer sitting underneath.

WorkOS FGA is Warrant, acquired in April 2024 and rebranded. Sensible if WorkOS is already your identity layer, but its pricing is absent from the page listing AuthKit and SSO numbers, so budget for a sales call.

Oso homepage now leading with agent safety

Oso needs a warning label. It built its name on an embeddable library and the Polar language; the homepage now opens with "Agents are here. Oso makes them safe," and the open-source osohq/oso repository has had no pushes since February 26, 2025. Go look at the commit history yourself before you build on the library.

Apache Casbin is the quiet giant of the group: 20,334 stars, currently in incubation at the Apache Software Foundation (it ships as "Apache Casbin (Incubating)"), with implementations in Go, Java, Node, Python, PHP, .NET and Rust. No network hop, no vendor. Also no control plane and no answer to "which objects." For a monolith that needs real ABAC, it is hard to beat.

What OpenFGA actually returns

Server v1.18.3 and CLI v0.7.20, installed from release binaries because the Docker daemon was down that morning. The model says a document inherits editors from its parent folder, and a folder grants editor to every member of a team:

type folder
  relations
    define editor: [user, team#member]
type document
  relations
    define parent: [folder]
    define editor: [user, team#member] or editor from parent
    define viewer: [user, team#member] or editor or viewer from parent
Enter fullscreen mode Exit fullscreen mode

Push it with fga store create --model model.fga, then write three tuples, not one of which touches the document directly: anna member team:platform, team:platform#member editor folder:engineering, folder:engineering parent document:roadmap. Now the checks:

fga query check user:anna editor document:roadmap   -> {"allowed":true}
fga query check user:bob  editor document:roadmap   -> {"allowed":false}
fga query list-objects user:anna viewer document    -> {"objects":["document:roadmap"]}
fga tuple delete user:anna member team:platform     -> {}
fga query check user:anna editor document:roadmap   -> {"allowed":false}
Enter fullscreen mode Exit fullscreen mode

Anna got to that document across two hops nobody explicitly granted her, then lost access because she left a team. Zero lines of application code were involved in either direction. That list-objects call is the one that replaces a hand-rolled SQL filter, and if you want to see the query it is standing in for, the SQL SELECT builder will assemble it.

What Cerbos actually returns

Same exercise with Cerbos v0.55.0, against a policy where managers can view and approve inside their own region under $5,000, and nobody may approve their own expense:

manager, us-east, $4,200, owned by anna    view: ALLOW   approve: ALLOW
manager, us-east, $7,500, owned by anna    view: DENY    approve: DENY
manager, us-east, $100,  owned by dana     view: ALLOW   approve: DENY
Enter fullscreen mode Exit fullscreen mode

The interesting row is the middle one. view gets denied as well, because the manager's only matching allow rule carries the amount condition with it. That is the class of bug you catch by testing decisions rather than reading rules. Row three is explicit deny overriding allow, expressed in three lines of policy. The original write-up walks through both policy files in more detail.

How to choose

Start from whichever question your product asks most often.

  • Users share resources and "list everything this user can see" has to be fast: relationship engine. OpenFGA for the gentler learning curve, SpiceDB when scale or consistency-immediately-after-revocation is a hard requirement.
  • Your rules are conditions over attributes you already hold: policy engine. Cerbos for YAML in Git, Cedar if you are on AWS, OPA if it is already deployed.
  • Non-engineers need to define or audit permissions: control plane, from $5/mo with Permit.io.
  • One service and no plans for a second: Apache Casbin.

Whichever shape wins, settle early on where permission data gets written. The single most common failure in relationship-engine rollouts is a code path that creates a resource and forgets to write its tuple.

If your policies live next to AWS IAM, the IAM policy generator is useful for sanity-checking the JSON that ends up sitting beside Cedar.

Getting off the roles column

  1. Write down the questions, not the roles. Phrase each as "can PRINCIPAL do ACTION on RESOURCE." Twenty of them cover most products, and they become your test suite.
  2. Model one resource type end to end against those tests, then run the engine in shadow mode next to the existing check and log every disagreement.
  3. Flip one endpoint behind a flag. Save list endpoints for last, because a bug there returns wrong rows instead of throwing an error you would notice.

Wrapping up

This decision is about where permission data belongs, not which vendor has better marketing. Relationship engines own the data and are strong on sharing and listing. Policy engines own no data, are strong on conditional rules, and give you Git as the audit trail. Both run fine on a laptop and both are open source, so test the fit before anyone gets on a sales call.

Two trends worth tracking. Pricing units now count machine identities, which will move your bill the day agents start calling your API on a customer's behalf. And the category is consolidating: Warrant became WorkOS FGA, Oso's library went quiet, OpenFGA climbed to CNCF Incubating. Re-check the repository and the pricing page on the day you actually decide.

References

Top comments (0)