Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Stack, an open-source Clerk/Firebase Auth alternative (stack-auth.com)
144 points by n2d4 10 months ago | hide | past | favorite | 70 comments
Hey HN! Happy to finally launch Stack. We made it because we like to put apps into production quickly, and authentication & user management was taking up way too much time.

We have components like <SignIn /> and <AccountSettings /> that automatically adapt to whatever theme & design system you're using. Check the blog post to see the example with Radix UI and Joy UI.

Also, there's an admin dashboard for monitoring and editing accounts. Stack is 100% AGPL/MIT-licensed, so you can self-host it.

Cheers!




> Despite how crucial it is, it's hard to find a service that has all the features you need for a successful product.

> That's why we built Stack.

I’m not convinced this is a strong USP. One could make a decent argument “Stack” doesn’t have “all” the features (yet) - I’ve seen the roadmap.

Firebase, Superbase etc. arguably have more features.

In a nutshell, I think it might be better to have that paragraph really drive home the USP of the product e.g., open source accountability, fairer pricing model etc.

Those are strong tells, instead of the “all the features” narrative. That’s a hard battle to win :)

Regardless, awesome work! And congrats on the launch


Appreciate the feedback! You're totally right, that paragraph is a bit of a mix of what we want it to be down the line (when it's feature-complete for enterprise) and what we have right now (which should be enough for startups, especially B2C, but not everyone).

I've edited the paragraph a little to reflect that. Hopefully, at some point in the future we can really say "all the features" ;)

In the end, you've recognized correctly that we see ourselves as an open-source company first and foremost.


No qualms! Congrats on the launch again


feels like if keycloak had been slightly better 10 years ago, backend architecture would be way less complicated and more standardized

auth system that worked well with static file buckets would cut like 40% of backend DB / server needs


Why don’t more people contribute / coalesce around Keycloak?

I don’t know if it was even that “bad” per se “10 years ago.” 10 years ago, React was only open source for 1 year. Meteor was Supabase. People were still writing CoffeeScript.

You are lamenting the complexity of changing authorization requirements without changing application code. I don’t know if OIDC was really set in stone back then. There was no Rego or Cedar, there were IAM policies, and that was also relatively new, and attributes-driven SAML. It’s just a lot of development has happened.


Auth is not a simple thing to do especially with the numerous accepted methods. Is there something that you think keycloak could do better?


I have a couple customers who use keycloak to handle SSO integration with my product. Almost every single time we do the configuration on a screenshare it is painfull. The gist is they all seem to have different setup with various configuration and asking me how to fix it but what works for someone doesn't work for someone else. Most of the time when things don't work, they start clicking things everywhere and that either make it worse or in some case make it work. As a vendor, I would love to have a way to give them a configuration that just work on both SAML and OIDC


None of this is very specific, but also matches my experience pretty closely.

Also, if you have Keycloak running behind Apache as a reverse proxy, I've had requests between those two randomly drop. I needed to change some obscure setting in the Apache config in regards to connection pooling/keep-alive or something along those lines, mentioned it in a past comment of mine. That was annoying, in addition to having to configure Keycloak in the first place.

But when it works, it works pretty well!


Can you summarize what differentiates this from Supabase and Supertokens?


Supabase is way more barebone and you have to implement the frontend and the user auth flow logic yourself. I talked with many people who use Supabase/Firebase auth and they all needed multiple days to make a full auth flow

Supertokens is pretty complicated and hard to set up in my opinion, but please tell me if you had a different experience


Tangential, but is anybody else holding on to serverside user management and sessions for their monolith? With an external auth provider, my backend would be making a http call for verifying each incoming request. We make drastic changes to backend user management (one provider says you dont need to maintain a users table) and frontend framework (Firebase is a pain for backend, Stack provides only React components).

Only Logto and Hanko seem to offer sane "I can vouch john@example.com logged in, create a user and start their session in Django if you please" workflow that can beat vendor lockin.


If you're looking for a system that has more features, is user friendly, a nice admin ui and easy deployments compared to Keycloak. Please give https://goauthentik.io/ a shot. Not affiliated in any way, just a very happy user.

It has

-an admin UI

- Supports (LDAP, SAML, OAUTH, social logins)

- MFA, Passkeys

- Application access based on user groups etc


This looks great! I was just looking in to Clerk as a solution for user management, so this is definitely a timely product, for me. And it looks to be a very easy integration because I could start out with the hosted version and then move to self hosting. I really like that feature!

Unfortunately, my project is not using jsx, so I can't really implement anything that relies on it. I would love to check this out, if I can use it without Next.js or any kind of jsx compatability. But, until then, it's not something useful for any of my use cases.


We support any stack via our API over here at Stytch, take a look! Would love to hear feedback.


Oh, awesome! Thanks!

Unfortunately, I'm not seeing much value-add over Clerk or Auth0. Looks like Stych is going to lock me in to a vendor just as much as the other two, so I'd have to compare them based on those merits alone.

So far, Clerk has a more permissive free tier for B2C users.

Also, it's a pretty big red flag - for me, personally - when a site promises that I can export my data, but requires me to request it via email rather than having a straightforward automated process that will provide me an export in an exact, known format. Put simply: if you haven't figured out how to automate data export (even with many complex options), then I don't have much faith in you to do other stuff with the care I would expect.


Appreciate the look and feedback!

> Also, it's a pretty big red flag - for me, personally - when a site promises that I can export my data, but requires me to request it via email rather than having a straightforward automated process that will provide me an export in an exact, known format. Put simply: if you haven't figured out how to automate data export (even with many complex options), then I don't have much faith in you to do other stuff with the care I would expect.

We let you export any and all data automatically from our API (via Search or Get Users), the only data we don't allow you to export by default is password hashes. Anything else you can pull at any time.

We require a human-in-the-loop process there so we can ensure out of band that the request is valid and not coming from compromised API keys etc. I'm not sure if there are any auth services that would provide an automated way to dump password hashes, I'd be nervous if there were given the security concerns.


Do you have federated LDAP anywhere on your roadmap? Are some features going to be Enterprise only eventually? We are currently evaluating Zitadel. How do you Stack(:D) up against them?


Upvoted for the pun. Nice one.


Professional opinion: I think a user management system without 2FA on day 1 is a nonstarter. It is, to me, the same as if it didn't have a password field.


What would be the benefit of using Stack compared to one of the existing OpenId Connect Providers like Auth0, Okta, Keycloak, Ory... ?


What would be a standout feature compared to other open source authN/authZ solutions like Ory or Keycloak?


Simplicity. Both of these require a lot of setup, and have less/no frontend integration. I would go with us if you are trying to focus on the rest of the app and not auth. The config you need to get started with us is nearly zero.


React/Next only


Working on it — vanilla JS support is pretty high up on our list


Yeah, I was going to ask if it’s react only, guess another product I won’t bother with.


My biggest issue with Clerk (aside from the since-validated suspicion their pricing would become downright predatory once they got sufficient adoption) was that if your product wasn't written in one of the SPA frameworks du jour it was basically unusable, unless you wanted your front-end integration driving your user data into your backend, which seemed like a security nightmare.

Why so many products will call themselves enterprise with no .NET, Java, etc. integrations available is part of why the existing products in those ecosystems are so expensive.

I look forward to playing around with Stack on my own and comparing it to Clerk but I couldn't seriously suggest this at work as there's no backend integrations.


Hey, (clerk founder) why do you think Clerk's pricing is predatory? Our goal is to continually lower prices and be as affordable as possible. Outside the free plan, it starts at $25 for the first 10k MAUs. Eventually we want auth to be as close to free as possible, while selling addt. services built on top of auth/users.

Also, the clerk service has layered integrations, powered by an http layer. We have customers using each part of the layer for varied integration types. That being said, the SDKs for the spa frameworks are the easiest to use.


Thank you for the question! It's very easy to rocket into $500/mo+ when you start needing your add-on features that I really think should be standard for any paid tier of something like "user management as a service." User impersonation, MFA, custom roles/permissions don't necessarily have scaling costs with them so charging more for these features seems predatory. But I trialed your product prior to these pricing changes so I don't have first-hand experience implementing them, maybe there is some justification for the added cost.

Do you still need to be in a paid tier in order to ban users? It's been a while since I tried your product out and I seem to remember that being the case in the early days.


Yeah coming up with our pricing model was and still is challenging. We're due for a revamp. As with most things in tech, all of these features require a ton of time to build / maintain / etc. so while the marginal cost isn't that high, the development time for all of them is very meaty and still ongoing.

If you were comparing something like build vs. buy where you had to build every feature clerk has from scratch, just paying for clerk would be soo much cheaper. But not every app needs every feature, and there's also a lot of open source options out there that make the build out a lot easier, so that comparison isn't completely fair.

But the main idea is that we wanted most apps to cost ~$25/mo - $100/mo, and, if you're building a B2B SaaS, you're going to have far fewer MAUs, and so we wanted the base cost to be higher at ~200/mo.

If you, or anyone reading this, ever feel like they're paying "too much" for Clerk - reach out to us and we'll work out a custom deal or even help you off-board to something else.

Banning users is still currently on the $25/mo tier which feels wrong, it should be in the free tier. We're due for a pricing revamp again quite frankly to make these pricing options more attractive. The tricky thing with the MAU costs is that a lot of folks seems to think they have a monster on their hands and forecast for like 1M MAUs or something, which is so far from reality.

It's tough to balance all of these competing priorities -- and if we don't have enough revenue, we can't keep building and investing in the platform for which we have pretty big ambitions. I will say that over a long period of time we want auth to be free and we want build applications to be 100x easier than they are today. I'm kind of getting ramble-y, but we also recognize that clerk's not for everyone and your use case might not make sense!


AGPL and MIT licenses are very (extremely?) different. What's the thinking there?


MIT for the client libraries, AGPL for the serverside


Realistically no one will be able to touch the AGPL code without paying the vendor, so "no vendor lock-in" claim is quite BS.


I'm not sure I follow your logic here, so I'd appreciate it if you void expand your thought a bit?

My understanding is that anyone can run the AGPL server. Anyone can modify it. Customers using the modified version can get that code.

I'm not sure where "paying the vendor" fits into this equation...


The issue is virality, i.e. derivative work of the AGPL software should also be AGPL, so it's unlikely that serious companies would be willing to take the risk of potentially exposing their entire non-auth stack to AGPL and having to argue the line for what would be derivative work and what is not.

Many big companies have blanket policies either banning AGPL completely, or require strict legal review.

Re the payment question: it is a common SaaS licensing model to dual license under AGPL and a commercial license. AGPL serves as a deterrent for business customers to use it without purchasing the commercial license.


Thanks for elaborating.

Yes, the use of AGPL as part of the stack certainly raises concerns. I don't think it would apply in this case, but equally I am not a lawyer, and i don't want to pay lawyers to fight over it, so personally I don't use AGPL in my stack, validating your point.


That's right. As long as you give back the source-code of any changes you make, you can self-host Stack. However, modifying without giving back is not allowed under AGPL, so companies that want to do that would need a commercial license. (Though we don't offer commercial licenses or anything like that right now.)


I know it's a subtle distinction, but I'd suggest avoiding the term "give back".

The AGPL requires that source code be supplied to users of the system. In other words "code flows down-stream". There us no requirement to flow the code "upstream".

Now sure, you might become a user of their service. Or you might get a user to pass the code onto you. And that may have the effect of you getting the changes they made.

But they are not "giving back", and they have no duty to do so.

I know it's a subtle difference, but I think it's helpful to be specific when it comes to legality- it avoids misunderstandings.


Is this not a solved problem in the frontend/backend world? Are there not plug and play libraries for auth on the backend and frontend for every popular language?


People want frameworks or standalone servers, probably driven by the web dev crowd wanting to only focus on product (shamefully, myself included)


Congrats on the launch!

I have a question - what if I want to integrate Stack with React and NestJs app? I couldn't find any docs for a backend authentication.


Seems really cool! Good luck and have fun :) I see that you list 2FA and SSO in the roadmap for the next weeks, those are definitely needed for enterprise.


Please address support for vanilla js/framework agnostic and what differentiates from Supabase and supertokens on ur site


Vanilla JS will come pretty soon, though we can't provide the "adapt to your design system" feature there. We have more features to get you started quickly than both Supabase and Supertokens on the frontend, but are (currently) missing some enterprise features on the backend in comparison to those (specifically 2FA and SSO/SAML).

Eventually, we want to catch up on the enterprise features but maintain the simple setup for the frontend.


Looks like they may support or will support pure js api

From GitHub readme: “We provide frontend and backend libraries for Next.js, React, and JavaScript”


Would love to see compatibility with existing Clerk integration! Then I could stop paying Clerk and pay you haha

will it adapt to PrimeReact


No PrimeReact yet, but won't be too hard to implement


I was literally discussing why a service like clerk should be open source a few days ago. This is such perfect timing.


Looks great! I’ve always felt the existing open source solutions are clunky and confusing.

Any plans to create components for Flutter?


Not sure yet. Flutter would require us to rewrite a lot of the client library, but on the other hand there aren't really any good Flutter solutions for this. Feel free to hop on our Discord and try convincing me :)


This looks cool, but I just don't understand why anyone would choose to do UI components for a project like this in Next/React instead of vanilla web components with a standard REST api, which can be used anywhere by anything.

Or, honestly, why anyone would chose to use react server components at all.

I was just kicking the tires on cal.com and saw the same thing - they did all their stuff with the react server components and next.js. And then? Well, it turns out that they needed an API, because apps do.

So they ended up reimplementing most of the logic in a RESTful API anyway.

I just SMH.


hey cofounder of cal.com here. the plan has always been to: 1. start and go fast with a mono repo and trpc fullstack api to understand and learn the fastest. once we knew what we need, we were able to build an external facing API. we wanted to be very clear to externals that using our “trpc api” is with caution due to undocumented breaking changes. a lot of companies have an internal API + external API (built later)


What I really want is the next step: the one where it manages user groups and roles. :)


Do you mean full user management? Via a UI or API? Or something else?


Frontegg has that


I like the docusaurus theme, you've build it yourself?


It is very close to the default theme, here you can find the custom CSS

https://github.com/stackframe-projects/stack/blob/main/docs/...


Looks great. Would love a redwood integration!


My first thought is why not supabase?


what's different from pocketbase?


Congratulations and welcome to the auth party!


Another product name impossible to find using google :D

On a more useful note... I kind of wonder what the target audience for this is. Big companies? Dont want to roll their own auth. Startups? Dont want to roll their own auth...


Most people will probably use the hosted version and be fine with it. Most of the value in this being open-source is that it holds us accountable — if we raised prices by 100x, you could just download a dump, fork the project and host it somewhere else (think of what happened with Redis recently). Another piece is that the community can vet its security. And of course, this lets everyone contribute to it.

Between big companies and startups, we're definitely targetting startups. Big companies have a wide variety of auth systems to choose from (Auth0, Keycloak, etc.)


I haven’t thought about this before but is this why drug names are so semi random? I always through the fake names were trying to invoke some similar idea to their name but is it basically just for SEO type purposes?


Because nothing was already called "stack"?


"Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting."

https://news.ycombinator.com/newsguidelines.html


I use this thing called STACK: https://stack-assessment.org/

It's unsearchable.


Better then X.


"I built a new programming language called `programming language`."


You'll have to increment the number: https://en.wikipedia.org/wiki/PL/I


Or even [1]. They also made dedicated keyboards for this one [2].

[1]: https://en.m.wikipedia.org/wiki/APL_(programming_language) [2]: https://www.keyboardco.com/product-images/ibm_model_m_beige_...




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: