Identity providers

Cerbos authorization for Supabase

Supabase provides authentication and a Postgres backend with Row Level Security. Cerbos adds application-level authorization that works alongside RLS, using Supabase user metadata and JWT claims to drive fine-grained access control policies.

App metadata as policy inputs

Use Supabase app_metadata fields like role, team, and tenant ID as principal attributes in Cerbos authorization policies

Complement row level security

Add application-level authorization alongside Supabase RLS for access control that combines identity with business context

Edge Functions and APIs

Call Cerbos from Supabase Edge Functions, serverless backends, or any API layer using the Supabase JWT claims

How Cerbos works with Supabase

Supabase handles authentication, confirming who a user is. Cerbos handles authorization, deciding what that user can do. Together they give you a complete access control stack without coupling identity logic to business rules.

Cerbos lets you write fine-grained, context-aware authorization policies in human-readable YAML. Policies are decoupled from application code so product and security teams can update permissions without a release cycle.

Because Cerbos runs as a stateless Policy Decision Point (PDP) next to your application, authorization checks are sub-millisecond and scale horizontally with your infrastructure.

Policy-as-codeHuman-readable YAML policies managed like source code Scalable PDPStateless policy decision point with sub-millisecond latency Centralized managementManage, test, and deploy policies from a single control plane

How Cerbos works with Supabase

Users authenticate via Supabase Auth, Supabase handles email/password, magic link, social login, and phone auth. Authorization-relevant data is stored in app_metadata on the user record and embedded in the JWT.
Extract identity from the Supabase JWT, Your backend or Edge Function verifies the Supabase JWT and extracts the user ID, app_metadata (role, team, tier), and any custom claims.
Send identity and resource context to Cerbos, Pass the Supabase user ID, app_metadata fields, and any additional context as principal attributes alongside the target resource and action to the Cerbos PDP.
Cerbos evaluates policies and returns a decision, Cerbos evaluates your YAML policies against the Supabase identity data and resource context, returning allow or deny. Your application enforces the result.

FAQ

Does Cerbos replace Supabase Row Level Security?

No. RLS and Cerbos serve different layers. RLS protects data at the database level for direct client-to-Supabase queries. Cerbos handles application-level authorization in your backend or edge functions. Use RLS as a safety net for direct database access and Cerbos for business logic authorization in your API layer.

How does Cerbos use Supabase user metadata?

Supabase stores user_metadata (user-editable) and app_metadata (server-only) on each user record. Set authorization-relevant data like role, team, or subscription tier in app_metadata via the Admin API. These values are included in the Supabase JWT and can be passed to Cerbos as principal attributes.

Can I use Cerbos with Supabase Edge Functions?

Yes. Verify the Supabase JWT in your Edge Function, extract the user's metadata and claims, and send them to Cerbos. This gives you fine-grained authorization at the edge without embedding access control logic in each function.