Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative
https://github.com/stack-auth/stack
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!
Congratulations on the launch Zai and Konsti!
I’m working on a hobby project that I had to build in basic email password auth using Auth.js due to a clients specific requirement.
I’ve experienced all the headaches you mentioned above, so I’ll be certainly taking a deeper look into this.
Again, great work!
Cheers!
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.
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.
They’re open source (Apache 2.0), developer friendly (nice, documented API), and handles authorization and user management well.
I see you plan on making money by charging for the hosted service. Given that, and given recent history in the industry with companies starting out with this model only to rug-pull it from users later and move to a more restrictive license, can you publicly commit to keeping the code MIT/AGPLv3-licensed into the future?
My site is a golang static site with a few pages as a reactjs spa. Do you guys planning on adding support for the general stack using something like the new web components API?
I'd change the name. The last time I saw a legit site with a hyphen in its name was probably early 2010s. It doesn't engender trust.
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...
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:
> 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.
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 helps us easily configure it. If you don't use Terraform or Pulumi, they have this really cool kickstart feature where you can define a config file that will call their APIs on first time startup to set up the server. Really useful for local dev.
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...
Congratulations on launching Stack Auth and providing a better alternative!!!
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.
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 would say we are to Ory what Clerk is to Auth0.
I suspect the answer is "no" here, but can Stack be used as an OAuth provider itself? I think all I see in the documentation is using other OAuth providers for authentication.
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.
On the other hand, Auth0 attempts to close of the complexity of the space by creating an opaque/proprietary layer. And then the primary pain point with Auth0 is that it's feature are behind another pricing tier.
If less complexity is what Stack Auth does differently than Keycloak. Does it do so by having a less transparent view of the auth process? Or does it do it by surfacing this complexity in a more digestible format?
I don't care. Transaction volumes to the auth are comparatively low and computers are cheap so keycloak is a good choice.
Quick question. How would this compare to supabase/gotrue [0] and permify [1]?
[0]: https://github.com/supabase/auth
[1]: https://github.com/Permify/permify
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.
Auth is literally the next thing I’m working on…
This came up on Reddit and the founder responded directly there, seemed like they were going to add a tool tip or something to make it clearer.
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.)
How does it compare?
(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.)
Wait, what? Do you role your crypto to handle standard auth flows? Is this some machine generated text?
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.)
Is it possible to automate the setup process ?
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.
I want to be able to just put self-hosted Clark in front of my postgres DB
but I'm forced to use Supabase because of its Auth integration and I don't know what open source self-hosted Authentication/Authorization out of the box exists
Lucia-Auth v2 left me just confused state. It's frustrating that everything requires $$$/month
I'm a big fan personally of Supabase-the-database; we've been building an integration so that you can combine RLS with all of our cool authZ features.
Also, do you support m2m tokens, ie. client credentials flow? What are the limits, if any?
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 ?
Anyways, here are a few things that might cost you time in the future that 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
what people smoke to do those features?
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.
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.
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.
Maybe I'm getting old and jaded, but that's not really the spirit of open source.
> 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.
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.
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.
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.
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.
Small things like: - the install script uses npm, I ran into a few dependency conflicts :( - the redirect url for google auth didn't work for me. (using github codespaces) - then gave up after that
Happy to work with you all to fix these small things! Overall it looks good and I would use it later if i'm not in a rush!
Any idea how easy it is to use with PGP / Symfony?
Also, cheeky wishlist request, any support for Mastodon logins?
> 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.
Open core vs. full open source, fair.
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?
1: https://database.dev/pointsource/supabase_rbac
Feel free to reach out to us if you have more questions or want to get started — email is in my bio.
That's to say the least.
Are you planning on implementing passkeys at all?
Could your service be a replacement for WorkOS. Currently I'm only using their Google OAuth and their Google SAML. I see that your SAML is paid only.
We use Ory right now, but it is very hard to setup and integrate into.
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!
https://github.com/authgear/authgear-server
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?