Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative

Original Article ↗ Hacker News Discussion ↗

An open-source authentication and authorization platform, Stack Auth, is being positioned as a developer-friendly alternative to Auth0, Clerk, and other incumbents, with a strong focus on Next.js, Postgres, and full-stack features such as organizations, RBAC, email flows, and user dashboards. Commenters weigh its promise of simple integration, self-hosting under AGPL/MIT, and transparent pricing against a crowded field of existing options like Supabase Auth, Ory, Keycloak, SuperTokens, and Zitadel, probing whether its differentiators and security posture are sufficient. The exchange also touches on broader concerns about VC-backed “open source,” the trade-offs between UX and security in component-based auth, and the long-term trustworthiness of hosted auth providers.

Product scope & goals

  • Stack Auth is pitched as an open‑source alternative to Auth0/Clerk focused on developer experience and deep integration with Next.js + Postgres.
  • Goes beyond basic authentication: organizations/teams, RBAC/permissions, user dashboard, impersonation, email flows, and (soon) TOTP‑based 2FA/MFA.
  • A setup wizard for Next.js generates pages, handlers, and config with a single command.

Comparisons to existing solutions

  • Compared against Supabase Auth: Stack Auth claims broader feature set (authZ, orgs, impersonation, dashboards) and is building Postgres/Supabase connectors to combine with RLS.
  • Versus Ory, Supertokens, Logto, Keycloak, FusionAuth, Zitadel, etc.: positioned as more “developer‑friendly,” less enterprise‑oriented, and more tightly integrated with specific frameworks.
  • Multiple commenters note crowded competition; some doubt the differentiation is strong enough.
  • Some ask for direct comparisons (including to keycloak, Zitadel, Propel Auth, Auth.js) and a clear feature matrix.

DX/UX & integrations

  • Strong focus on Next.js (app router), with a dedicated SDK and components. REST API is framework‑agnostic; other stacks (Golang, Django, Rails, vanilla React, etc.) are planned but not yet first‑class.
  • Some users had friction (npm dependency issues, OAuth redirect troubles); maintainers invite bug reports and plan more language examples.
  • Components run on the app’s own domain rather than redirecting to a hosted login page, which some see as better UX but others argue trades off security vs. classic redirect‑based auth servers.

Licensing, hosting & business model

  • Dual license: client libraries under MIT, server under AGPL. Some confusion about AGPL is clarified; it is still open source and does not force open‑sourcing the whole product.
  • Monetization is via hosted SaaS and support; maintainers publicly commit to keeping core code open source and compare their model to Supabase.
  • SAML and some enterprise‑style providers are implemented when paying customers request them, but contributions land in the OSS codebase.

Security & trust

  • Commenters press for clear security policies, pen‑testing and architecture docs.
  • Project adds a SECURITY.md and notes reliance on battle‑tested lower‑level auth libraries, but concerns remain about delegating auth to a young project.

General sentiment

  • Many express enthusiasm, relief at an OSS Clerk‑like option, and frustration with Auth0/Clerk pricing and lock‑in.
  • Others are skeptical about yet another auth platform, VC‑backed open source, and the complexity vs. rolling simpler in‑house auth.