Get the top HN stories in your inbox every day.
saled
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.
n2d4
To quote myself from another comment chain:
> 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.
dang
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 of talk about how critical it is to be transparent and fair with your community. The consensus is that things tend to go well if you do that and badly if you don't.
The focus for these open-source companies is finding a natural way to carve out the free vs. paid parts of the space. By 'natural' I mean something that is a good fit for the domain and that both sides feel is fair. The free users know it's in their interest for the company to make money because that's how the whole thing is sustainable. People just need to feel that the paid product is one that it makes sense to charge for and that it's a fair exchange.
The most common way to do this is to open-source the product and offer a paid cloud offering. There are other approaches which I remember I found rather interesting, but unfortunately I forget the details because thanks to HN I never remember anything anymore!
But the main thing is no, not only are these founders not looking for ways to screw their open-source users, the seasoned ones are advising the junior ones to shy away from the slightest trace of that. The model by which an open-source company is making money needs to be as transparent and unimpeachable as possible.
One downside is that it's hard to get this right from the beginning, and changes can be messy. From what I've heard, the consensus is that if you keep a good relationship with your community at every step, and preserve transparency as an invariant, then it's at least possible to explain why a change is necessary and get through a messy phase that way.
klabb3
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 patterns, keeping basic features behind their cloud offerings. The mega corps sometimes swoop in and take all the candy from the kids. Products are designed suboptimally, eg kubernetes native when they would be much better as a library. Then you have honest well meaning players who lose customers to self-hosting, because they need on-prem for security reasons, or simply because they want better debugging and logs.
Some varied examples off the top of my head include Docker, Hasura, Redis, Hashicorp, Benthos. My point here is combining small-medium sized businesses with a core FOSS product is full of perils, risk and unhealthy market dynamics. I’d assume the iceberg is also much bigger than these prolific projects, from companies that chose not to do FOSS in the first place.
theredsix
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.
ramonverse
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.
no_wizard
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.
mooreds
> 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.
undefined
digitcatphd
Same here. I’d rather them be transparent with the price and just undercut them. Last ‘open source’ YC project I reviewed almost felt like a hidden trap paywall. If they could cut my bill in half I’d switch, there is no reason Auth0 should charge so much. On the contrary another YC project just cut their competitor pricing and we are using them.
rudasn
This looks very refreshing! Congrats for officially launching,I think StackAuth was mentioned here before.
What are your plans for supporting "old school" frameworks, like django, rails, bootstrap, et al?
I know that it makes sense to target greenfield projects first, and I presume most new projects are started with some new cool tech (if looking at npm downloads or some other vanity metric or online questionnaire), but I think there's a long tail of users of other tech that would potentially provide high quality feedback based on real world experience at various settings.
I'm only saying this as it looks like you want to own the whole auth stack, all the layers and all the workflows, from dba to sales so to speak.
n2d4
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.
psankar
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 about it. Incorporating your project, its lifecycle management, etc. seems more work than implementing a 3-4 APIs (/signup /signin /verify-email /forgot-password /reset-password) and a periodic job (trigger emails and stuff). Is it so complex that we should bring in a new dependency with its own deployment, backup, monitoring etc. lifecycle management ?
n2d4
First, incorporating Stack into your project is really easy if you use Next.js — literally just a single command:
npx @stackframe/init-stack@latest
.
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, and JWTs should not be long-living
- Impersonation to debug users or do customer support early on
- A user dashboard for basic analytics & editing, saves you from having to build this yourself in Retool
- Email shenanigans — for example, some mail clients click verification links automatically to check them for spam and then even interact with the page
- User profiles and account settings pages
- OAuth access token management, if you ever want to access APIs on the user's behalf
- App-based 2FA with HOTP/TOTP — we don't actually have this yet, but should be released this week still
- Redirects, so users land back on the same page after they successfully logged in
- Teams, so you can segment your B2B clients
- Access permissions for your users
- and more stuff, every time I make this list it's slightly different
throwaway2037
Nice list. You came well prepared.
> Email shenanigans — for example, some mail clients click verification links automatically to check them for spam and then even interact with the page
n2d4
Check for cookies. If they exist, we can continue like normal. If not, require user interaction (none of the spam filters we tested click buttons, but from what I could gather, one of them — Outlook — moves the mouse).
1oooqooq
identifying those clients and emails using it would make for some easy account take over using password resets.
what people smoke to do those features?
cpursley
Most mature web frameworks (ie, not Janky JavaScript stacks) handle this either out of the box or by pulling in a popular community library. The benefits are no separate service to run and operate and the user model being directly tied to the database.
nwellinghoff
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.
Too
Sorry, I'm very well versed in the authentication space, but after spending 10 minutes browsing the documentation i truly can't understand the architecture. There are no drawings, it just jumps straight to npx install or comparing itself to other solutions, assuming i know all of them.
Is this a frontend UI? Is it an authentication proxy? Is there any data stored? ..where? What are the different deployable components? What runs in my own backend, in the frontend or in the cloud? If it is managed and requires an API key, what part is open source?
jay-barronville
This is really awesome. On almost every project I’ve worked on, I’ve never been able to trust and truly rely on proprietary services and companies to handle my authentication and authorization. I’ve been forced (i.e., it was already decided) to use Auth0 before and I hated every minute of it.
Congratulations on launching Stack Auth and providing a better alternative!!!
selcuka
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?
n2d4
This exact set of problems is precisely what we're trying to solve. Reading this feels like great validation :)
throwaway2037
This is a great HN anecdote. Can you share more about why Auth0 was frustrating? I would like to learn more.
yashap
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!
n2d4
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.
yashap
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.
5Qn8mNbc2FNCiVV
I found Supertokens hellish to use because of their Singleton approach and the "recipes" whatever that is that makes searching the docs a mess and also the integration. Also find their react sdk is pretty bad but eh. The nodejs part however is pretty good and I like that most functions can be overridden
treve
Absolutely wild how many of these there are now! I feel like I'm reading an announcement like this every few weeks.
localfirst
I think its a sign of a bubble
samstave
There's been a lot of actually useful things in this bubble it seems. Ive been truly inspired how much little tool-age has been popping up.
I feel like if you took a bunch of literally just that last month of show/launch/announce HN things one could wrap up a whole secure, scalable, promptable, fully formed stack thats just looking for some sort of content.
localfirst
when you see crowding in one segment its always indicative of a looming recession
danpalmer
Congrats on the launch. What's your approach to security? I notice there's no mention of any penetration testing, no security policy, no responsible disclosure policy, no place to report security vulnerabilities.
You're absolutely right (in other comments) that getting the UX and so on right for authn/authz is really hard, and there are a ton of edge cases, but I know from experience that there are a ton of security edge cases too. Things like rotating session tokens at the right time, how that interacts with password resets, HTTP referrers, etc, is all quite tricky to get right. I've built with battle-hardened, decades-old frameworks and still gotten a few details wrong.
To delegate all of this responsibility to a third party product, even if it's open-source, rather than building it yourself, is to give up control. Sure you can edit the code, but can you find the bug in an unfamiliar codebase, effectively test in a testing environment your unfamiliar with, and create a valid build? That's a lot harder.
If I were to delegate that responsibility to a product like this, I'd want to know that they've taken security at least as seriously as I do, ideally much more seriously because it's the core of their product. Right now I'm not convinced.
n2d4
We added a security policy: https://github.com/stack-auth/stack/blob/dev/.github/SECURIT...
If it helps you, we delegate the most vulnerable parts of the application, such as OAuth, to lower-level frameworks — similar to the unmanaged auth libraries people use today. We are essentially a thick wrapper around those, to create a full-stack platform from primitives. (Of course, that doesn't mean the thick wrapper cannot be vulnerable, but it helps with some of the most hideous bugs.)
The point I disagree with is that building it yourself is better than delegating it to a third-party — at best, you can secure your auth against vulnerabilities you're aware of. Unfortunately, this fallacy keeps coming up, but generally it's the case that homebrew auth is not more secure than open-source libraries, nor is proprietary code.
danpalmer
Thanks for adding a security policy.
To be clear I'm certainly not suggesting people write their own auth from scratch. My point is more that even when using mature frameworks it's possible to miss necessary bits or accidentally cause vulnerabilities around the edges. My experience here is building auth on Django's built in auth system which is fantastic. The issue comes when you start customising session management (for real product use-cases!), without then understanding all the interactions between various flows. As we were using a framework in our application, fixing these sorts of issues was straightforward, however if we had used a third-party hosted application (even if running on our own infra), it would likely have been far harder to spot the issues and address them.
n2d4
Understood. Thanks for clarifying :)
esafak
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 proprietary. Open-source solutions like Supabase Auth or Auth.js/NextAuth are only authN, and don't provide the rest of the toolchain.
n2d4
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.esafak
If you want to be developer friendly, create examples for as many languages as you can, and include them in the documentation, and as GitHub repos. Don't say "it's REST, DIY!"
n2d4
Noted, thanks. We're focussing on Next.js frontends right now — which is fairly well-documented — I hope to get some Python & Golang examples in there by the end of the week.
rudasn
I think a comparison table here would be better for you here, considering your target audience and all.
MrDarcy
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.
vhfdbbvfdv
[dead]
telesilla
How does this compare to Ory Kratos, also an open source option - https://www.ory.sh/comparisons/ory-versus-auth0/
n2d4
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.
lordofgibbons
Unless you have extensive experience in the auth space, the Ory documentation and ecosystem is utterly undecipherable.
duggan
Hi Zai and Konsti!
I expect we're in your target demographic, small team using Next.js and Supabase with a lot of ambition and not enough time in the day :)
Stack Auth is one of those things I didn't quite realize I might want – we're using Supabase Auth at the moment during our EAP, with Nango as an OAuth proxy, and I've been hesitant to build out organizations without a good reference implementation – we've rolled it ourselves before and never been really satisfied with the results. At the moment we're rolling a deployment-per-org, which is ok for small teams, if a little cumbersome to manage, but we'll need a solution for larger companies. I've had supabase_rbac[1] in the back of my mind for this.
Stack Auth seems like it could solve a few of these, but do you see yourselves proxying APIs for OAuth, or will you leave that to other service providers?
n2d4
Sounds great! Yep, I think Stack would be a good fit. We don't proxy APIs, instead we just give you the access token and refresh it automatically so you can pass it alongside your requests to the original endpoints. If you want to proxy requests for some reason (analytics, observability, etc), you may want to keep using Nango, Panora, or the like.
Feel free to reach out to us if you have more questions or want to get started — email is in my bio.
Lord_Zero
Have you seen this? https://github.com/logto-io/logto
How does it compare?
n2d4
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.)
Get the top HN stories in your inbox every day.
Hi HN! We're Zai and Konsti, and we're building Stack Auth (https://stack-auth.com/), an open-source managed authentication and authorization platform. Basically, we build your login and signup pages, and everything that comes with that.
Our GitHub repo is at https://github.com/stack-auth/stack, and there’s a zero-budget demo video here: https://www.youtube.com/watch?v=LTkjdPf2E2Q
Stack Auth was born out of years of frustration with the incumbents. We wanted to build something that is developer-friendly and open-source at the same time.
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 proprietary. Open-source solutions like Supabase Auth or Auth.js/NextAuth are only authN, and don't provide the rest of the toolchain.
On the other hand, building your own auth infrastructure is tedious work. Rolling your own crypto is already hard enough, but on top you'll have to deal with OAuth flows, access tokens, RBAC, permission syncing, API keys, and so on. Most handcrafted OAuth or password-based applications in the wild are vulnerable in at least some of these areas.
To us, the solution to this was obvious, so we decided to build it. Stack Auth is 100% open-source, licensed under MIT and AGPL. You can self-host, or choose to use our managed hosting. If you choose the latter, there's no lockin. You can export all your data and/or start self-hosting at any time.
Also, we're more than just authentication — we have authorization (orgs, teams, permissions, RBAC) and user management (impersonation, user dashboard, webhooks).
One interesting feature is what we call "connected accounts": we can manage and refresh your OAuth access tokens even for services that your users don't use for sign in, such as when accessing GMail or OneDrive APIs.
We also put a lot of weight into integrating deeply into the tech stack itself. For now, we support Next.js frontends with a bunch of components and hooks for sign-in, password reset, and organizations. 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.
For more info, check out our GitHub repo above, or our documentation (https://docs.stack-auth.com).
Would love to hear about your own stories and opinions on auth. Thanks all!