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

Kratos is geared towards enterprises and less developer-friendly. We integrate very closely into the tech stack that we currently target, which is Next.js + Postgres, and want to make setup as straight-forward as possible.

I would say we are to Ory what Clerk is to Auth0.

Unless you have extensive experience in the auth space, the Ory documentation and ecosystem is utterly undecipherable.

Supabase Auth: We do much more than them — e-mails, organizations, permissions & RBAC, user dashboard, impersonation are some of the features we have. (I like Supabase a lot as a DB — we're working on some fancy connectors to use Stack Auth alongside Supabase RLS, so you can get the best of both worlds.)

Supertokens, Ory: Developer-friendliness and integrations, mostly (both of these target enterprise customers). Also, Supertokens is open-core. I'd say we're to Supertokens/Ory what Clerk is to Auth0.

I think its a sign of a bubble

In theory yes — actually, we already are an OAuth provider behind the scenes — though we haven't documented this anywhere yet. What would you use it for?

Appreciate the feedback! We have the following in our GitHub README, which we should probably copy to our frontpage:

    > # How is this different from X?
    >
    > Ask yourself about X:
    >
    > - Is X open-source?
    >
    > - Is X developer-friendly, well-documented, and lets you get started in minutes?
    >
    > - Besides authentication, does X also do authorization and user management (see feature list below)?
    >
    > If you answered "no" to any of these questions, then that's how Stack Auth is different from X.

Unfortunately, Web Components are still somewhat immature [1], but eventually, our plan is to support vanilla React as well. We really want to nail every single integration that we officially support before growing horizontally, because looking at some of our competitors, often its greatest failures come from rushing framework support.

So, we went with the most popular JS framework first (Next.js), and are gonna go from there once we're confident in it.

[1] https://dev.to/richharris/why-i-don-t-use-web-components-2ci...

You might like what we built then — we have a setup wizard that adds auth to your Next.js project for you, including creating all the necessary pages, handlers, and config ;)

   npx @stackframe/init-stack@latest

Yes. Both Zai and I care a lot about FOSS — we also believe that open-source business models work, and that most proprietary devtools will slowly but surely be replaced by open-source alternatives. Our monetization strategy is very similar to Supabase — build in the open, and then charge for hosting and support. Also, we reject any investors that don't commit to the same beliefs.

From the OP:

> Though, we do have a well-documented REST API (https://docs.stack-auth.com/rest-api/auth), so you can access Stack from any language.

Our backend and dashboard are language-agnostic, and you can access their REST API from anywhere. However, there is a Next.js SDK with server & client components, hooks, and functions that integrate very deeply into the framework — that one is Next.js-only.

We also have a setup wizard, which installs Stack Auth into your project, which works only on Next.js apps with the app router. It's as simple as:

    npx @stackframe/init-stack@latest

I’ve used FusionAuth as well and found it to be quite good.

Thanks for mentioning FusionAuth, Theo.

For anyone curious about his experience or other folks experience, we have a series of interviews on our blog here:

https://fusionauth.io/blog/tag/community-story/

Here's the Switchboard post: https://fusionauth.io/blog/switchboard-reduced-migration-tim...

Not right now, but we're working on a native Postgres extension as part of our Supabase integration — which would let you do that.

Indeed, we launched an MVP in Show HN a few months ago — dang messaged us and said we should apply to YC, which we did, and now we're launching here again, officially. :D

We will definitely support those frameworks too, eventually. Though, we think that each integration must be done very carefully — we'd rather have excellent support for one framework and capture its entire audience before going horizontally, than ten mediocre integrations that give our users a headache on setup. We went for Next.js first because a) it's the most popular JS framework for new projects right now, and b) existing Next.js auth is pretty shit.

This exact set of problems is precisely what we're trying to solve. Reading this feels like great validation :)

This is a great HN anecdote. Can you share more about why Auth0 was frustrating? I would like to learn more.

Curious. There are already many alternatives (some open source) to Auth0 such as Keycloak, Zitadel, SuperTokens, etc. What makes Stack Auth different in your opinion?

Our clients are MIT, our servers are AGPL.

Surprisingly your the only one who has mentioned Keycloak so far?! I switched several projects from Auth0 to it some time ago and didn't look back... particularly when they started tightening things since said projects were not even profitable.

Keycloak is a pain to set up, and its configuration tends to get quite messy — besides, we try to cover integrations into the entire stack (frontend to the database).

I keep repeating this comparison throughout this thread, but Stack is to Keycloak/Ory/etc. what Clerk is to Auth0.

Though, I regularly recommend Keycloak in sales calls when I talk to larger companies willing to invest time and effort into a custom IdP. We are not really looking to replace those use cases.

Supabase Auth is only authentication; it doesn't do organizations, permissions/RBAC, impersonation, etc. We are working on some fancy Postgres connectors to let you use Stack Auth with the DB part of Supabase and RLS.

GoTrue and Permify are on a lower abstraction level than us; we connect the entire stack (from frontend to database), while GoTrue and Permify still require a lot of setup and manual integrations.

Clerk has quite a few dark patterns in their free tier, eg: if your app is on Clerk free tier, all your users will be forced to log out and re-login every 7 days (and they try to obfuscate this fact until you're locked in). For this reason, I've recently had to migrate away from them - I'm really glad there are alternatives.

I've literally been building this right now, currently doing E2E tests! Should be done by end of the week. (and it'll be free for everyone)

Auth0 is the same with MFA pricing, absolutely ridiculous.

Logto's focus is on enterprises, while ours is on the developer experience for startups and side projects. I've used this line in a few comments on this thread already but I'd say that Stack is to Logto what Clerk is to Auth0.

(For Logto specifically, I'm actually surprised by what they consider "enterprise" features — something like OIDC, 2FA or RBAC should not be gated behind a paywall, IMO.)

You must encrypt and salt passwords and retrieve them without being susceptible to timing attacks. PKCE. 2FA/TOTP as well.

Yes.

But it will show our name and logo, and we limit shared key usage to a few users per project, so we highly recommend you set up your own keys before going into production. (The dashboard will let you know in time.)

Everything is open-source.

We implement providers when a paying customer requests them (Team plan for OIDC-compatible providers, Growth plan for everything else, including SAML). Once we've implemented them, though, everyone benefits.

To our surprise, as of right now we haven't received any requests for SAML from our customers.