Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative
Stack Auth is an open-source user authentication solution for developers, offering quick setup, self-hosting, and features like OAuth support, user dashboards, and role-based access control, promoting community contributions.
Read original article
Stack Auth is an open-source user authentication solution designed as an alternative to Clerk/Auth0, aimed at developers. It is licensed under MIT and AGPL, allowing for a managed authentication experience that can be self-hosted. Developers can quickly set up Stack Auth in about five minutes, with support for Next.js frontends and any backend that can utilize its REST API. Key features include authentication components for sign-in and sign-up, a user dashboard for managing user data, account settings for profile updates, multi-tenancy for B2B management, role-based access control, OAuth connections, user impersonation for support, webhooks for user interactions, customizable email notifications, and efficient user session management with JWT handling. Installation involves using Docker and following specific setup commands. Stack Auth also promotes community engagement by encouraging contributions and showcasing projects built with the platform. Developers can find contribution guidelines in the repository and join the Stack Auth Discord community for further collaboration.
- Stack Auth is an open-source alternative to Clerk/Auth0 for user authentication.
- It supports quick setup and self-hosting of user data.
- Key features include OAuth support, user dashboards, and role-based access control.
- Installation requires Docker and specific setup commands.
- Community contributions and projects are encouraged through the platform.
Related
Identity: Self-Hosted or in the Cloud?
Authentik Security introduces open-source Identity Provider, favoring self-hosted solutions for enhanced control and pricing predictability. Shift to self-hosting challenges SaaS dominance, offering comparable reliability and security with improved manageability. Companies prioritize data privacy and flexibility, reflecting nuanced evaluation of needs.
Authelia and Lldap: Authentication, SSO, User Management... for Home Networks
Setting up Authelia and lldap for home network user management involves Docker, configuration files, secrets, Redis, Let's Encrypt, and Caddy for secure HTTPS connections. Enhance security and user management with this guide.
- Many users express interest in the open-source nature of Stack Auth, contrasting it with proprietary solutions like Auth0 and Clerk.
- Several commenters raise concerns about security practices and the complexity of integrating a new authentication system.
- There are requests for comparisons with other open-source authentication solutions, indicating a competitive landscape.
- Users are curious about specific features, such as support for older frameworks, 2FA, and custom domains.
- Some commenters share their past frustrations with existing solutions, highlighting the need for a reliable alternative.
54 commentsMaybe I'm getting old and jaded, but that's not really the spirit of open source.
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.
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 ?
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?
Congratulations on launching Stack Auth and providing a better alternative!!!
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.
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.
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?
Quick question. How would this compare to supabase/gotrue [0] and permify [1]?
Here’s an example. To retrieve the current user, simply call:
export function MyComponent() {
const user = useUser({ or: "redirect" });
return <div>{user ? `Hi, ${user.displayName}` : 'You are not logged in'}</div>;
}
That’s it! Stack will either return a User object or redirect the user to the login page.
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!
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.
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.
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?
We use Ory right now, but it is very hard to setup and integrate into.
Also, do you support m2m tokens, ie. client credentials flow? What are the limits, if any?
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.
They even have a lambda feature to add additional logic around certain workflows or adding claims to your JWTs.
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.
Any idea how easy it is to use with PGP / Symfony?
Also, cheeky wishlist request, any support for Mastodon logins?
Are you planning on implementing passkeys at all?
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!
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!
That's to say the least.
Wait, what? Do you role your crypto to handle standard auth flows? Is this some machine generated text?
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
Related
Identity: Self-Hosted or in the Cloud?
Authentik Security introduces open-source Identity Provider, favoring self-hosted solutions for enhanced control and pricing predictability. Shift to self-hosting challenges SaaS dominance, offering comparable reliability and security with improved manageability. Companies prioritize data privacy and flexibility, reflecting nuanced evaluation of needs.
Authelia and Lldap: Authentication, SSO, User Management... for Home Networks
Setting up Authelia and lldap for home network user management involves Docker, configuration files, secrets, Redis, Let's Encrypt, and Caddy for secure HTTPS connections. Enhance security and user management with this guide.