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

Original Article ↗ Hacker News Discussion ↗

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.