From Supabase to Clerk to Better Auth
Third‑party authentication services like Clerk and Supabase are facing growing skepticism as developers weigh convenience against reliability, lock‑in, cost, and loss of control over user data. Many argue that modern frameworks (Django, Rails, Laravel, Phoenix) or libraries such as Better Auth now make it feasible to keep auth in one’s own database while still supporting social login, SSO, and other “enterprise” features. The debate centers on whether outsourcing auth truly reduces risk and effort, or simply moves critical complexity into opaque, failure‑prone dependencies that can become expensive and hard to escape.
Better Auth vs. Clerk (and Supabase)
- Pro‑Better Auth comments highlight:
- Auth data lives in your own database, not a vendor’s.
- One CLI command to set up tables; works with any DB provider.
- Many built‑in features (OAuth providers, plugins, JWT, offline/mobile support, iframe auth) and open source; optional managed hosting.
- Perceived as more “hackable” and transparent than SaaS products; easier to debug.
- Free for self‑hosted use; attractive vs. per‑user SaaS pricing.
- Critiques of Clerk include:
- Heavy, slow JS bundles and complex isomorphic TS code; painful upgrades and dependency conflicts (e.g., with Stripe).
- Missing enterprise features (e.g., audit logs, configuration versioning).
- Operational issues: outages, token refresh failures, no robust offline auth on mobile.
- Confusing or limited RBAC model; org‑scoped roles only.
- Some defend Clerk, noting strong adoption (e.g., large startups), good for rapid prototyping, and that online complaints may be skewed.
Framework Auth & “Roll Your Own” Debate
- Many argue mature frameworks (Django, Rails, Laravel, ASP.NET Core, Phoenix/Elixir) ship solid auth, user, and role systems; no need for separate SaaS.
- Others point out that “auth = users table + hashed password” is outdated; modern apps often need SSO, SAML, SCIM, OAuth/OIDC, MFA, passkeys, social login, multi‑tenant orgs, etc.
- Some describe building custom auth as feasible but time‑consuming; bugs around rate limiting, 2FA, lockouts, and SSO are common.
- Distinction is drawn between:
- Not rolling your own crypto or security protocols vs.
- Sensibly using libraries and running auth yourself vs.
- Delegating everything to a hosted SaaS.
When to Outsource Auth
- Pro‑SaaS arguments:
- Auth is a “productivity tarpit”; non‑differentiating but critical.
- Third‑party vendors handle security, certifications, and complex enterprise SSO demands.
- Reduces in‑house ops burden (vs. running Keycloak, etc.).
- Anti‑SaaS arguments:
- Extra critical dependency reduces overall availability; reliability is roughly the product of all critical components.
- Vendor lock‑in, pricing risk, opaque behavior, and limited customization.
- Hard migrations (password hashing differences, SSO/SCIM/passkey re‑setup, parallel cookie handling).
- Some see piling Supabase + Clerk as a red flag for security maturity.
Alternatives & Ecosystem Notes
- Mentioned options: Auth0, WorkOS, FusionAuth, Keycloak, Ory, Authelia, Authentik, Lucia (now mostly documentation), and framework‑specific libraries (e.g., Rails “authentication‑zero”).
- Consensus trend in the thread: move away from hosted auth SaaS toward libraries or self‑hosted systems that keep user data local, unless enterprise SSO needs and team constraints strongly justify a service.