OpenFGA vs SpiceDB vs Cerbos vs OPA vs AWS Verified Permissions: Which Authorization Platform to Choose

Building custom authorization works for many applications. Distributed systems increasingly benefit from dedicated authorization infrastructure that handles policy evaluation, relationship management, and fine-grained access control as a service. A reasonable default: keep authorization in an embedded library while it stays inside one service, and adopt an external engine once it crosses a service boundary.

The choice of engine follows from your dominant model. Cedar and AWS Verified Permissions suit attribute-driven decisions on AWS. SpiceDB and OpenFGA suit access that follows relationships between users and resources. Cost, operational overhead, and policy language lock-in decide the rest.

What Changed in the Authorization Market

OPA/Styra disruption: Apple acqui-hired Styra’s co-founders and core team. Styra DAS (the commercial OPA management platform) is transitioning to community-maintained open source as enterprise commercial support ends. OPA remains under CNCF governance, but enterprise users face uncertain commercial support. Many are evaluating alternatives like Cerbos, Cedar, and Permit.io.

ReBAC mainstream adoption: Google Zanzibar-inspired systems (SpiceDB, OpenFGA, Permify) have moved from academic curiosity to production infrastructure. OpenAI uses SpiceDB for ChatGPT Enterprise connectors, handling tens of billions of fine-grained permissions.

Policy language fragmentation: Cedar (AWS), Rego (OPA/CNCF), Polar (Oso), OpenFGA DSL, and Cerbos YAML/CEL represent a Cambrian explosion of policy languages. The industry has not converged on a standard, though Cedar and OpenFGA DSL are gaining momentum.

Non-human identity explosion: AI agents, service accounts, and machine identities now significantly outnumber human users in many enterprises. Authorization systems must handle agent-to-agent delegation and continuous policy enforcement. Most legacy systems were not designed for either requirement.

AWS Verified Permissions price reduction: AWS reduced pricing for single-authorization APIs (IsAuthorized, IsAuthorizedWithToken) by up to 97% to $5 per million requests in the published US rate card. Batch APIs (BatchIsAuthorized, BatchIsAuthorizedWithToken) and policy management APIs use separate per-call or tiered schedules. See Amazon Verified Permissions Pricing. This makes cloud-native fine-grained authorization economically viable for many high-volume applications when you model the right API mix.

Market consolidation: Permify was acquired by FusionAuth. WorkOS acquired Warrant (Zanzibar-based FGA). Auth0 FGA is now marketed as Okta FGA. The space is consolidating around a few well-funded players.

RBAC, ABAC, and ReBAC

Platform selection follows from the access model you already have, so it is worth naming that model before reading any feature matrix.

RBAC (Role-Based Access Control)

Roles are assigned to users. Permissions are attached to roles. This works well when roles are stable and access does not depend on resource context. It breaks down with dynamic access requirements, multi-tenancy, and resource-level sharing. Every platform supports RBAC as a baseline, so it rarely narrows a shortlist.

ABAC (Attribute-Based Access Control)

Decisions are based on attributes of the user, resource, action, and environment. ABAC excels at conditional logic: time-based access, location restrictions, compliance rules. Policy languages like Cedar, Rego, and Cerbos YAML/CEL express ABAC well. The trade-off: ABAC is more expressive but harder to audit and reason about than RBAC.

ReBAC (Relationship-Based Access Control)

Access is determined by relationships between entities. This is the Google Zanzibar paradigm: “User X is editor of Document Y, which is in Folder Z.” Platforms like SpiceDB, OpenFGA, and Auth0 FGA implement ReBAC natively. The trade-off: ReBAC is excellent for collaborative applications but requires maintaining a relationship graph, which introduces the dual-write problem.

Layering Models in One System

Systems in production usually layer them: RBAC carries the baseline, ABAC adds contextual conditions such as time, IP, or a risk score, and ReBAC covers resource-level sharing and inheritance. An ACL on a specific resource acts as a local override. Permit.io and Oso Cloud are built for that layering; with other platforms you stack the systems yourself.

Cloud Provider Platforms

AWS Verified Permissions + Cedar

Cedar is declarative, formally verified, and fast. Benchmarks show it evaluating policies 28-35x faster than OpenFGA and 42-80x faster than Rego. Note that these benchmarks compare fundamentally different architectures: Cedar evaluates local policies while OpenFGA traverses a relationship graph, so direct speed comparisons should be interpreted with that context. Single authorization APIs are $5 per million requests after the reduction; batch and policy management rates differ. See Amazon Verified Permissions Pricing and AWS Cognito + Verified Permissions for SaaS for a cost breakdown.

Integration is native with Cognito, API Gateway, AppSync, and Lambda. In a SaaS product, Cognito handles authentication and tenant-aware token generation while Verified Permissions makes the fine-grained decision from those tokens. The main limitation is that Cedar is ABAC-focused with no built-in relationship graph. If you need Google Docs-style sharing, Cedar alone is insufficient.

Microsoft Entra ID

Entra ID is an identity platform with coarse-grained authorization capabilities. It is not a fine-grained authorization engine. The Conditional Access engine evaluates signals in real time: user identity, device state, IP location, sign-in risk, and application context. It answers “can this user access this application?” and stops there. Resource-level questions such as “can this user edit this specific document?” fall outside its scope.

What Entra provides: app roles as JWT claims for simple RBAC, group-based authorization, custom security attributes (P2 feature), Entra External ID for B2C/B2B, Workload ID for non-human identities, and Permissions Management (CIEM) across AWS, Azure, and GCP.

Fine-grained application-level authorization (ABAC/ReBAC), policy-as-code engines, and relationship-based access control sit outside that scope. For a resource-level decision like “can user X edit row Y in tenant Z,” you need an external authorization system: Entra handles identity verification, session management, and risk assessment, and an external PDP (Cerbos, OPA, AWS Verified Permissions, or SpiceDB) decides from Entra’s JWT claims plus resource context.

Entra earns its place in a Microsoft-ecosystem enterprise for workforce identity, Conditional Access, and compliance, with one of those engines behind it.

Google Cloud IAM + Identity Platform

Firebase Authentication with Identity Platform supports SAML, OIDC, multi-tenancy, and MFA. But Google does not offer a dedicated fine-grained authorization service comparable to AWS Verified Permissions. Custom claims on tokens work for simple RBAC but do not scale for complex authorization models. For Firebase and GCP applications with simpler needs, that is often enough.

Independent Vendors and Open Source

Auth0/Okta FGA: If Auth0 or Okta already issues your tokens, the FGA add-on stays inside that account. It is built on OpenFGA (open-source, Zanzibar-inspired), supports up to 100 billion relationships and 1 million requests per second with a 99.99% SLA, and is ReBAC-focused with limited ABAC capability.

SpiceDB/Authzed: The most mature open-source Zanzibar implementation. Used by OpenAI for ChatGPT Enterprise, handling tens of billions of permissions. ZedTokens provide consistency guarantees. ReBAC-focused; ABAC requires workarounds. Self-hosted requires PostgreSQL/CockroachDB and Kubernetes expertise. For a detailed comparison with Auth0 FGA, see SpiceDB vs Auth0 FGA: Relationship-Based Authorization.

Cerbos: Purpose-built application authorization engine using YAML and CEL, which keeps a team out of Rego and Cedar. Deploys as a single binary, container, or sidecar, and the learning curve is low. No built-in relationship graph; it must be paired with another system for ReBAC.

OPA (Open Policy Agent): CNCF graduated project and general-purpose policy engine, with its strongest ecosystem in infrastructure policy (Kubernetes admission control). Rego is powerful but has a steep learning curve (~30-40 hours to proficiency). The Styra acqui-hire has created uncertainty around commercial support.

Permit.io: Authorization-as-a-service built on OPAL, with OPA, OpenFGA, or Cedar as backend engines. That multi-engine layer means a later engine switch does not force a full rewrite.

Keycloak: CNCF incubating project for identity and access management, self-hosted, with authorization bundled in. Java-based and resource-heavy (512MB-2GB RAM per instance). Not purpose-built for fine-grained authorization.

WorkOS FGA: Acquired Warrant (Zanzibar-based FGA). Extends RBAC with hierarchical, resource-scoped access control, integrated with SSO (SAML), Directory Sync (SCIM), and Audit Logs in a single B2B SaaS bundle.

Where the Decision Point Runs

Where the policy decision point runs matters as much as which engine runs it. That choice sets the latency floor, the blast radius when the engine is unavailable, and how much infrastructure authorization consumes.

Central Service, Sidecar, or In-Process

Deployment	Strength	Weakness	Fits
Central PDP service, called over the network	One source of truth, simple audit and policy management	Single point of failure, a network hop per decision	Low decision volume, few services
Sidecar container next to each service, policies synced from a management plane	Local evaluation, no network dependency for a decision	Resource cost per pod, sync complexity, eventual consistency	Kubernetes, high volume, latency-sensitive paths
Embedded library in-process (Casbin, CASL, Cedar SDK)	Fastest path, no extra infrastructure	Language-specific, policies hard to manage across services, no central audit	Single-language stack, simple policies

Gateway Coarse, Service Fine

These tiers combine well, which is why the diagram above shows both. The gateway answers “can this user reach this API?” from a JWT and a role check. The service answers “can this user perform this action on this record?” through a sidecar or embedded PDP, with relationship data synced from a central authorization service and audit records aggregated centrally. AWS API Gateway with a Cognito authorizer and Verified Permissions is one implementation, Kong with the OPA plugin another. Coarse checks up front keep the fine-grained decision volume, and its cost, manageable.

What It Costs at 100 Million Decisions a Month

Cost tracks decision volume, operational overhead, and team expertise more than list price. Approximate monthly figures:

Platform	Monthly Cost	Infrastructure	Operational Overhead
AWS Verified Permissions	~$500	None (managed)	Low
SpiceDB (self-hosted)	$500-2,000	K8s + DB cluster	Medium-High
Authzed (managed)	Custom pricing	None (managed)	Low
Auth0 FGA	Bundled/Custom	None (managed)	Low
Cerbos (self-hosted)	$100-500	Minimal containers	Medium
OPA (sidecar)	$200-800	Per-pod sidecar	Medium
Keycloak	$300-1,000	Java VMs	High

Narrowing the List

Build vs. Integrate

The first decision is whether you need an external authorization system at all.

Managed vs. Self-Hosted

Platform Selection Matrix

Criterion	AVP/Cedar	Auth0 FGA	SpiceDB	Cerbos	OPA	Oso Cloud	Permit.io	Keycloak
RBAC	Good	Good	Good	Good	Good	Good	Good	Good
ABAC	Excellent	Limited	Limited	Excellent	Excellent	Good	Good	Good
ReBAC	Limited	Excellent	Excellent	Limited	Limited	Excellent	Good	Limited
Learning Curve	Medium	Medium	Medium	Low	High	Medium	Low	High
Self-Hosted	No	No	Yes	Yes	Yes	No	Partial	Yes
Managed Option	Yes	Yes	Yes (Authzed)	Yes (Hub)	Sunset*	Yes	Yes	No
Multi-Cloud	No	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Formal Verification	Yes	No	No	No	No	No	No	No
Open Source	Engine only	OpenFGA	Yes	Yes	Yes	No	OPAL only	Yes

*Styra DAS (the managed OPA option) is transitioning to community-maintained open source as enterprise commercial support ends following the Apple acqui-hire.

Where These Projects Go Wrong

Picking the Tool Before Naming the Model

Teams often pick a tool first and then try to fit their requirements into it. A team choosing SpiceDB because it sounds impressive will struggle if their authorization is primarily attribute-based. The opposite mistake is just as common: a monolith with straightforward roles does not need SpiceDB or AWS Verified Permissions, and CASL or a middleware check covers it. External systems earn their cost once authorization crosses a service boundary. Define the model first (RBAC, ABAC, ReBAC, or a layered mix), then select the platform that supports it natively.

The Dual-Write Problem

External relationship stores require keeping authorization state synchronized with application data. Without a strategy (outbox pattern, CDC, reconciliation), authorization decisions will drift from application reality. Budget meaningful engineering time for this. For a detailed walkthrough with implementation patterns, see SpiceDB vs Auth0 FGA: Relationship-Based Authorization.

Policy Language and Vendor Lock-In

Policy languages are not interchangeable: a migration means porting every rule and every test that guards it. Choose one you can commit to for years, or use an abstraction layer (like Permit.io) that supports several engines, and count the team’s learning investment as part of the price. The same caution applies to the project behind the language. The OPA/Styra acqui-hire showed that open source with a single commercial backer can lose that backer, so the governance model (CNCF, independent foundation, single vendor) belongs in the evaluation.

Two problems tend to surface after the platform decision. Authorization policies are code, so they need unit tests, integration tests, and a CI/CD pipeline; every major platform supports policy testing and teams still skip it. And an RBAC-only system eventually meets the “we need one exception” request, which is why a platform that can express more than roles is worth choosing before the exception arrives.

Living With the Choice

The embedded-library default holds while authorization stays inside one service and roles stay stable. Override it when access crosses service boundaries, when users share individual resources, or when a compliance rule needs attributes the application layer does not carry. Run a proof of concept with your most complex authorization scenario before committing, because switching platforms in production is expensive.

Later parts of this series cover AWS Cognito + Verified Permissions for SaaS, SpiceDB vs Auth0 FGA, and Cedar vs Rego vs OpenFGA policy language comparison.

References

• Cedar Policy Language Documentation - Official Cedar language reference, grammar specification, and policy writing guides
• AuthZed SpiceDB GitHub Repository - Open-source Google Zanzibar-inspired authorization system with documentation and examples
• OpenFGA Documentation - Open-source Zanzibar-inspired authorization engine powering Auth0/Okta FGA
• Okta Fine Grained Authorization - Auth0/Okta FGA product overview and architecture documentation
• Cloud Native Now - Apple Buys Styra Brains, OPA Remains Open - Coverage of the OPA ecosystem disruption following Apple’s acqui-hire
• Cerbos - Framework for Evaluating Authorization Providers - Vendor-neutral evaluation criteria for authorization platforms
• Permit.io - Policy Engine Showdown: OPA vs. OpenFGA vs. Cedar - Comprehensive policy engine comparison with syntax examples
• Teleport - Security Benchmarking Authorization Policy Engines - SPEF framework benchmarking Rego, Cedar, OpenFGA, and Teleport ACD
• OWASP Microservices Security Cheat Sheet - Authorization patterns for microservices including PDP/PEP/PIP
• Amazon Verified Permissions Pricing - Single versus batch authorization and policy management rates
• AWS - Amazon Verified Permissions reduces authorization request price - Announcement of the single-authorization API price reduction (up to 97%)
• Microsoft Learn - Conditional Access Overview - Entra ID Conditional Access policies, signal evaluation, and Zero Trust enforcement