Authorization (RBAC / ABAC / ReBAC)
Who can do what — once you know who they are.
Auth answers who is this. Authorization answers what can they do. They're different problems with different tools, and most apps grow into needing a real authorization layer somewhere between "10 users" and "first enterprise customer."
Hosted services
- ★ Permit.io — drop-in authorization with a polished UI (policy editor, audit logs); generous free tier; layers on top of OPA / Cedar internally.
- Oso Cloud — relationship-based authorization with a hosted query engine; small free tier.
- Auth0 Fine-Grained Authorization (FGA) — managed OpenFGA (since Auth0 created it); free tier on Okta / Auth0.
- Cerbos Hub — hosted Cerbos with policy management UI.
- WorkOS Authorization — bundled with WorkOS for enterprise.
Open source / self-host
- ★ Cerbos — Go service; YAML / Cerbos-DSL policies; runs as a sidecar or library; great for ABAC. The default OSS pick in 2026.
- ★ OpenFGA (Auth0 / CNCF) — Google Zanzibar-style relationship-based authorization. Use this when your model is "user ↔ resource" graphs (Drive sharing, GitHub repos, Notion pages).
- AWS Cedar — open-source policy language from AWS; embeddable as a Rust library (with TS / Wasm bindings).
- Casbin — language-agnostic; Go / Node / Python / Java SDKs; supports RBAC / ABAC / ReBAC; very mature.
- Oso (open source: Polar lang) — formerly OSS, partially shifted to Cloud; check current licensing.
- OPA (Open Policy Agent) + Rego — generic policy engine; powerful, steep curve. Underlies many of the above.
- SpiceDB (Authzed) — Zanzibar-style ReBAC; OpenFGA's main competitor.
- Topaz (Aserto) — combines OPA + a directory service.
In-app libraries (don't run a separate service)
- ★ CASL — TypeScript-first; "isomorphic" rules that work on client and server. Default for full-stack TS apps that don't need a separate authz service.
- AccessControl (npm) — RBAC + ABAC; older.
@casl/react,@casl/vue— bind CASL to UI to conditionally render.- Ory Keto — CNCF Zanzibar-style; pairs with Ory Kratos for full identity + authz.
Database-level
- ★ Postgres Row-Level Security (RLS) — built-in policies, enforced by the DB. The default for Supabase apps; works with any Postgres.
pg_graphql+ RLS — GraphQL with RLS-enforced authz.- MySQL VIEWs / triggers — DIY RLS; less ergonomic.
When to pick what
- Roles only ("admin / member / viewer"): a simple RBAC table is enough. CASL or rolling your own is fine.
- Attribute-based ("only this org's members can edit, only paid plans can publish"): Cerbos, AWS Cedar, OPA, or CASL.
- Relationship-based ("share document X with user Y; user Y can also share if they have edit permission"): OpenFGA or SpiceDB.
- Multi-tenant SaaS, every customer = an org: combine RLS for data isolation + CASL/Cerbos for action policies.
Patterns to know
- Decision logging — every authz check should be loggable for audit / debugging. Cerbos, OpenFGA, Permit all log decisions.
- Latency — ReBAC graph queries can get expensive; cache with sub-100ms targets.
- Test policies as code — Cerbos and OpenFGA have testing frameworks; treat policies like code with PRs and reviews.
- Don't bake roles into JWTs for fast-changing permissions — JWTs are cached; permission changes shouldn't require re-login.
Pick this if…
- Default new TS app, modest needs: CASL.
- Real authz service, OSS, ABAC: Cerbos.
- Document-sharing / Drive-style ReBAC: OpenFGA.
- All-in on Postgres: Postgres RLS + CASL for action checks.
- Want a UI for non-engineers to author policies: Permit.io.