## **Where Supabase Auth fits well** Supabase Auth is a practical fit when the application already uses Supabase services and the team wants fast setup for standard login flows. Its core feature set includes passwordless login with magic links and one-time passwords, social logins, phone authentication, built-in CAPTCHA protection, and helpers for web and mobile frameworks. Supabase Auth is also attractive when access control can stay close to the database. JWT claims flow into Postgres RLS, which lets a team enforce access rules without standing up a separate identity provider. For straightforward products, that coupling can feel efficient rather than restrictive. The problem appears when identity and authorization stop being simple. Once the product needs a clearer role model, broader tenancy support, or permission logic that spans services outside Postgres, Supabase Auth starts to look narrow.
## **Why teams look beyond Supabase Auth** The core limitation is not authentication. The limitation is scope. Supabase Auth covers sign-in and token issuance, but the authorization model remains something the team builds manually with tables, relationships, and Postgres policies. That trade-off has consequences. The application becomes more dependent on one database model, multi-tenancy becomes harder to reason about, and permission logic becomes more expensive to review and change over time. Backward compatibility across releases is not always guaranteed, which adds friction for teams that want stable long-term patterns. This is the main framing for the rest of the comparison. Some alternatives solve the identity problem. Other alternatives solve the permission problem. Very few tools solve both cleanly in one place.
## **The main Supabase alternatives** ### **SuperTokens** SuperTokens is an authentication solution that focuses on simple login flows. SuperTokens provides prebuilt UI, email and password login, passwordless login, social logins, multi-factor authentication, and built-in session management. SuperTokens is the closest Supabase alternative when the goal is to keep authentication lightweight while removing the Postgres dependency. The limitation is scope. SuperTokens does not try to be a full identity provider, and SuperTokens does not cover broader authorization or more advanced federation requirements. ### **ZITADEL** ZITADEL is a cloud-native identity provider that supports Single Sign-On, MFA, passwordless login, self-hosted deployment, and managed SaaS. ZITADEL also includes multi-tenancy concepts through organizations, projects, and scoped policies, plus APIs, SDKs, and Terraform support. ZITADEL is a stronger Supabase alternative when the requirement has moved from simple login to a broader identity platform. The trade-off is that ZITADEL is still an identity provider, not a dedicated fine-grained authorization engine. Some integration gaps also remain for apps that do not support OIDC or SAML natively. ### **Authentik** Authentik is a self-hosted identity provider with MFA, SSO, OIDC, OAuth2, SAML, LDAP, proxy mode, customizable flows, and an admin UI. Authentik can also enforce MFA and SSO in front of applications that do not support those features directly. Authentik is a stronger fit than Supabase Auth when the team needs protocol coverage, proxy mode, and flexible identity workflows. The trade-off is operational weight. Setup is complex, resource use is heavier, and advanced scenarios often require Python scripting. ### **Keycloak** Keycloak is a Java-based identity and access management system with SSO, MFA, social logins, federation with external identity providers, and built-in clustering. Keycloak is widely used when protocol support, legacy integration, and enterprise familiarity matter. Keycloak is a stronger alternative when the real gap is federation and identity infrastructure. The cost is complexity. Keycloak is heavy to run, complex to configure, and still limited on the authorization side to coarse-grained models. ### **Hanko** Hanko is an authentication service focused on passwordless login and onboarding. Hanko supports WebAuthn, FIDO2, passwords, MFA, social logins, SAML SSO, web and mobile SDKs, and both self-hosted and managed deployment. Hanko is relevant when the main need is a cleaner authentication experience, especially around passwordless flows. Hanko is not a broad identity platform, and Hanko does not solve advanced authorization requirements.
## **Supabase Auth compared with the main alternatives** The cleanest way to compare these tools is to compare them on scope first. Supabase Auth, SuperTokens, and Hanko are mainly authentication products. ZITADEL, Authentik, and Keycloak are broader identity platforms. [Cerbos](https://www.cerbos.dev/) sits in a different layer and handles authorization rather than sign-in. **Supabase Auth** works best for products that already use Supabase and Postgres. The main limitation is that authorization stays manual inside RLS and the model stays tied to one database backend. **SuperTokens** works best for teams that want simpler authentication and session handling without a full IdP. The main limitation is that identity management and authorization remain out of scope. **ZITADEL** works best for teams that need a fuller identity provider with multi-tenancy and automation support. The main limitation is that ZITADEL still does not replace a dedicated authorization engine. **Authentik and Keycloak** work best for teams that need protocol coverage, federation, and self-hosted identity control. The main limitation is operational complexity. **Cerbos** works best when the real pain point is authorization rather than login. Cerbos does not replace authentication, but Cerbos can remove permission logic from database policies and application code.
## **When the real gap is authorization** This is the part many Supabase comparisons miss. Supabase Auth can authenticate users, but Supabase Auth does not provide a built-in role-based permission system. The application team has to build authorization manually on top of RLS. Cerbos is an authorization management platform, it provides fine-grained and contextual authorization. Cerbos externalizes policies from application code, supports RBAC, ABAC, and PBAC, logs every decision, and is optimized for sub-millisecond evaluation. The practical integration pattern is straightforward. Supabase handles sign-in and token validation. The application reads the Supabase user and role data, then sends the principal, resource, and action to Cerbos PDP. Cerbos PDP returns an allow or deny decision, and the application enforces that result. The [Supabase integration guide](https://www.cerbos.dev/blog/cerbos-supabase) follows exactly that pattern. A login route authenticates the user through Supabase. A protected route validates the bearer token with Supabase, extracts the role from user metadata, and asks Cerbos whether that user can read a document resource. That pattern keeps authentication and authorization separate, which makes each layer easier to reason about. Cerbos Hub belongs in the evaluation when teams using Cerbos PDP need more structure around policy operations. Cerbos Hub adds advanced enterprise features such as policy authoring UI, programmatic policy management, and interactive playgrounds. Cerbos Hub complements Cerbos PDP when the team needs governance and workflow around policy changes.
## **What is the best Supabase alternative** The best Supabase alternative depends on what needs to change. If the goal is lighter authentication without a Postgres lock-in, SuperTokens is the closest fit. If the goal is a fuller identity platform, ZITADEL, Authentik, or Keycloak are better fits. If the real problem is authorization, replacing Supabase Auth may not be the first move at all. In that case, the more direct step is to keep Supabase for authentication and move authorization into Cerbos PDP.
## **Key takeaways** * Supabase Auth is strongest when the product already runs on Supabase and Postgres and the login requirements are still standard. * Supabase Auth becomes harder to scale when authorization logic grows beyond straightforward RLS policies. * SuperTokens and Hanko are closer alternatives when the goal is simple authentication without a full identity platform. * ZITADEL, Authentik, and Keycloak are better alternatives when the requirement has expanded into identity infrastructure. * Cerbos addresses the part Supabase Auth leaves manual, which is fine-grained authorization across services and resources. Cerbos also provides features such as: policy authoring, policy management, and governance. ## FAQ ### What is the best Supabase alternative? The best Supabase alternative depends on the scope of the problem. SuperTokens is a close fit for lightweight authentication, while ZITADEL, Authentik, and Keycloak fit broader identity requirements. If the main problem is authorization, Cerbos is often the more direct addition. ### Is there an open source alternative to Supabase Auth? Yes, there are open source alternatives to Supabase Auth. Options include SuperTokens, Authentik, Keycloak, Hanko, ZITADEL, and Cerbos, although these tools do not all solve the same layer of the stack. The right comparison starts with whether the need is authentication, identity management, or authorization. ### Supabase vs SuperTokens Supabase vs SuperTokens is mainly a comparison between database-coupled auth and a lighter authentication layer. Supabase Auth integrates directly with Postgres RLS, while SuperTokens focuses on login flows and session management without becoming a full IdP. SuperTokens is the closer fit when Postgres coupling is the main concern. ### Supabase vs Authentik Supabase vs Authentik is mainly a comparison between a focused authentication service and a fuller self-hosted identity provider. Authentik brings protocol support, proxy mode, custom flows, and an admin UI. The trade-off is more setup and more operational overhead. ### Supabase vs Keycloak Supabase vs Keycloak is mainly a comparison between developer-friendly auth inside a backend platform and a heavier identity system built for federation and enterprise integration. Keycloak offers broader identity features and protocol support. Keycloak also brings more operational complexity and still does not replace dedicated fine-grained authorization. ### Can Supabase handle authorization on its own? Supabase can handle authorization through PostgreSQL Row-Level Security, but this remains something the team builds manually. That is why authorization often becomes the next design problem. ### Can I use Supabase with Cerbos? Yes, Supabase can be used with Cerbos. The [integration guide](https://www.cerbos.dev/blog/cerbos-supabase) shows Supabase handling login and token validation while Cerbos evaluates whether the authenticated user can perform a specific action on a specific resource. That split keeps authentication and authorization in separate layers. ### Do I need to replace Supabase Auth to use Cerbos? No, Supabase Auth does not need to be replaced to use Cerbos. Cerbos works as a complement to Supabase when stronger authorization is needed. That makes Cerbos a practical next step when sign-in already works but permission logic is getting hard to manage.