Live data from Hacker News

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

github.com

131–140 of 146 posts

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

#131

As someone who came from Auth0 and god-awful Amazon Cognito, we've been using FusionAuth for years. Their APIs and SDKs have been amazing to work with. They even have a lambda feature to add additional logic around certain workflows or adding claims to your JWTs. https://fusionauth.io It does what Auth0 does but significantly more cheaper and you can also self-host if you want. I built the Pulimi plugin for it which…

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...

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

#132
Heya, congrats on launch! Welcome to the authN/authZ/user management party!

I work for a competitor (FusionAuth) but think that there's plenty of room to solve this for developers. I love the fact that you have a self-hostable option as we've found that for a set of developers, that flexibility really matters.

I think that Clerk has shown there's an appetite for components that handle common user management tasks. I think they had a blog post about how components are the new APIs, but can't find it. I'm a bit surprised it has taken so long for an OSS competitor with your messaging to emerge.

Where I stand depends on where I sit (ofc), but I think that component based solution trade security for UX and DX. That tradeoff may make sense for some applications, but it's good to walk into it with eyes wide open.

There's a reason that a redirect to an isolated, hardened Authorization Server (to use OAuth nomenclature) is the standard and that modern RFCs like OAuth 2.1 discourage developers from using the password grant (which is essentially what every component library is doing).

I believe a redirect is the correct option because if you isolate all user interaction to that server via a browser redirect, you can:

* lower the amount of code that handles sensitive PII and user credentials

* lock down access to this system

* delegate changes to specialized internal teams or vendors

* easily increase the security of the authentication process for existing applications without any code changes by ratcheting the security up at the Authorization Server (requiring additional factors or passkeys, for example)

The cost comes from the redirect. A redirect is fine for many traditional applications, but is not great for SPAs and, to a lesser extent, mobile apps. I believe this has a UX impact, though I haven't been able to find any numbers or studies and we've got plenty of customers who are doing fine with this approach.

There's also a DX impact because styling the Authorization Server pages may not use the same technology stack or deployment process as the rest of the application.

Anyway, congrats again on your launch!

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

#133
post #90

Hmm. Am I the only one who immediately jumps to the thought that any VC backed "open source" tool is just using open source as a cost of customer acquisition, and will soon find a way to pay-wall necessary features? The majority of the effort will be in the paid SaaS product, not the open source stuff. Maybe I'm getting old and jaded, but that's not really the spirit of open source.

> Am I the only one who immediately jumps to the thought that any VC backed "open source" tool is just using open source as a cost of customer acquisition

I wrote a blog post that touches on this tangentially: https://www.mooreds.com/wordpress/archives/3595

Even if they pay-wall necessary features (or are forced to by investors), the software can be forked.

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

#135
post #51

A bit of a meta point, but Clerk must be doing really well if they're already positioned as the thing to make alternatives to.

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.

Cofounder of Clerk here - we definitely want free plan users to be aware of this limitation - any suggestions to improve visibility?

On https://clerk.com/pricing , “Customizable session duration” is listed as a primary benefit of the pro plan, and in the chart we show that the free plan is “Fixed to 7 days”

Apologies we failed to make it clear before you started, that’s definitely not intended. We thought this was a good limitation for the free plan because it doesn’t impact your ability to learn if your product is resonating. If it is, and our default doesn’t work for your app, then we hope you can upgrade now that your product is validated. (It’s maybe worth mentioning that the default of 7 days was selected by copying Google’s session lifetime, also not meant to be nefarious.)

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

#136
post #80
post #74

Congrats on the launch. I have a golang backend, postgres db and a react app. I have added auth using email, password salting and saving in pg. It was about 1 day of work to implement all of this. I do not have OAuth or SAML however. Is that the differentiating factor, if I have to use your solution ? Is a basic auth setup such a complex thing to handroll ourselves ? I do not intend to be snide but genuinely curios a…

First, incorporating Stack into your project is really easy if you use Next.js — literally just a single command: npx @stackframe/init-stack@latest If you use our managed hosting, we'll deal with deployment, backup, ... for you. . Anyways, here are a few things that you'd have to build for yourself but come for free with Stack Auth: - Session management, because you probably don't want to store passwords in cookies,…

Nice. Do you guys also provide all the UIs for permission management/roles/orgs such that I can just css it and bolt it on? That was always a major pain point for me. You still had to make all the user facing ui and integrate it.

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

#137
post #90

Hmm. Am I the only one who immediately jumps to the thought that any VC backed "open source" tool is just using open source as a cost of customer acquisition, and will soon find a way to pay-wall necessary features? The majority of the effort will be in the paid SaaS product, not the open source stuff. Maybe I'm getting old and jaded, but that's not really the spirit of open source.

I think COSS is great, it makes the code more secure and auditable and makes sure the developers get paid to fix security vulnerabilities. Volunteer OSS is great in theory but it sometimes leads to overworked developers being exploited by foreign intelligence services https://www.techrepublic.com/article/xz-backdoor-linux/ . Supabase & Nextjs are part of the so called VC backed open source and they are great.

My opinion is that Supabase is one of the best models for OSS business we have seen. Do they get everything right? No, but they embody the spirit and adjust slot based on community feedback.

Vercel on the other hand, not so much. They’re closing the loop on multiple open source avenues and have been making features Vercel hosted only for awhile now. It’s getting harder and harder to properly and easily self-host Next.js for example.

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

#138
post #113
post #111

How would you compare yourselves to SuperTokens ( https://supertokens.com/ )? I ask because they’re another open source, YC backed auth system, and one that I’ve quite enjoyed using on a side project. There seem to be a lot of similarities between you two, would be interested to hear your take on the differences!

Quoting from another comment chain: > 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 the “developer friendly” critique is a fair one for Ory, especially Ory Keto, which I found to be an absolute nightmare to use. But as a dev I found SuperTokens really easy/nice to use.

Open core vs. full open source, fair.

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

#139
post #129
post #102

Earlier quoted context omitted.

YC does an 'open source panel' every batch where people come to hear from founders of successful open-source startups in order to learn the ropes. I've attended 4 of those by now (I think), so I have a sense of what gets said about this stuff from within the YC space at least. I haven't heard anyone talk about ways to "pay-wall necessary features" or otherwise exploit users into paying. On the contrary, there's a lot…

While I do take your word very seriously and believe it’s 100% honest, it seems incongruent with most things I’ve seen and experienced over the last decade or so. There’s to me a very real crisis or at least dilemma for businesses that would love to do FOSS but can’t or won’t for unfortunate reasons. Products are frequently over-complicated so self-hosting is difficult. There are often outright rug-pulls or dark patt…

You should evaluate the FOSS software features AS IS and ask if you're okay with the current feature set if all future features are behind an "enterprise" tier. If you are, and the hosting of the current version is manageable, then the product is good for both sides. I've often found running the numbers for paying the vendor for cloud vs amortizing devOps costs comes out in favor of the cloud version. I see this as a win-win for both the customer and the company.

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

#140
post #10
post #8

I'd suggest preparing a comparison table on the home page, at least against open source competitors, to help prospects decide. You emphasize completeness (authz + authn), and simplicity here: The dominant player in this space is Auth0, who appeals to enterprises but lags behind in developer-friendliness and has strong vendor lock-in. A newer one is Clerk, which markets directly to devs, but is still entirely propriet…

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 a…

How are you different than ZITADEL specifically?

They’re open source (Apache 2.0), developer friendly (nice, documented API), and handles authorization and user management well.

Post reply on HN