Supabase Auth and authorization gaps: what should teams do next?

TL;DR: Supabase Auth works well for fast sign-in on a Supabase and Postgres stack, but its authorization model stays manual in RLS and becomes harder to govern as roles, tenancy, and cross-service permissions expand, according to Cerbos. The practical issue is not login, but the growing cost of maintaining policy logic in one database layer.

NHIMG editorial — based on content published by Cerbos: Supabase Auth alternatives and authorization trade-offs

Questions worth separating out

Q: How should security teams decide whether to replace Supabase Auth or keep it and add authorization separately?

A: Teams should replace Supabase Auth only when the authentication layer itself is the constraint, such as when they need broader federation, protocol support, or a different identity operating model.

Q: Why does RLS-based authorization become harder to govern as applications grow?

A: RLS becomes harder to govern because the access model is tied to one database schema, which pushes roles, relationships, and tenancy rules into manual policy construction.

Q: What do teams get wrong when comparing Supabase Auth with identity platforms like Keycloak or ZITADEL?

A: Teams often compare them as if they solve the same problem, when they actually sit at different layers.

Practitioner guidance

• Separate authentication from authorization in the target architecture Keep Supabase for sign-in if it is already working, but move permission evaluation into a distinct policy layer when access rules are growing beyond simple RLS.
• Map where policy logic currently lives Inventory whether authorization is embedded in database policies, application code, or both, then identify the routes that depend on manual table relationships.
• Re-evaluate tenancy and cross-service access before scaling Check whether your current model can represent multi-tenant access and service-level permissions without duplicating rules across schemas.

What's in the full article

Cerbos' full article covers the operational detail this post intentionally leaves for the source:

• Side-by-side product comparison of SuperTokens, ZITADEL, Authentik, Keycloak, Hanko, and Cerbos for implementation planning
• Concrete integration pattern showing how a Supabase token is validated before the Cerbos policy decision is evaluated
• Practical guidance on when to keep RLS, when to externalize authorization, and how to think about policy operations at scale
• Feature-level distinctions such as session handling, federation support, and policy authoring workflows

👉 Read Cerbos' comparison of Supabase Auth alternatives and authorization options →

Supabase Auth and authorization gaps: what should teams do next?

Explore further

View Full Forum →  |  NHI Foundation Course →