Notifications
Clear all
Topic starter
10/06/2026 11:11 pm
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.
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
12/06/2026 5:01 am
Supabase Auth alternatives are really a governance decision about where authorization should live. The article makes clear that authentication is not the problem as much as the manual policy layer around RLS. When access logic has to be built table by table, teams end up governing permissions through database design choices instead of through a distinct identity control model. The practitioner conclusion is to treat authorization location as an architecture decision, not a feature comparison.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means entitlement review is still operating without complete inventory discipline.
A question worth separating out:
Q: Can an organisation keep Supabase Auth and still improve access governance?
A: Yes. The cleanest path is to preserve Supabase for authentication and externalise authorization into a dedicated engine when policy complexity starts growing. That lets the team keep the current login experience while removing manual access logic from database policies and application code, which reduces long-term governance friction.
👉 Read our full editorial: Supabase Auth alternatives: where authorization starts to break
