HN Explorer

Show HN: Stack, an open-source Clerk/Firebase Auth alternative (stack-auth.com)

144 points by n2d4 ↗ HN
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!

73 comments

[ 2.6 ms ] story [ 48.7 ms ] thread
[deleted]
(comment deleted)
[deleted]
(comment deleted)
alexchamberlain
AGPL and MIT licenses are very (extremely?) different. What's the thinking there?
n2d4
MIT for the client libraries, AGPL for the serverside
tgma
Realistically no one will be able to touch the AGPL code without paying the vendor, so "no vendor lock-in" claim is quite BS.
bruce511
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...

n2d4
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.)
bruce511
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.

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

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

officialchicken
React/Next only
tamimio
Yeah, I was going to ask if it’s react only, guess another product I won’t bother with.
pc86
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.

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

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

bsid
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!

n2d4
Working on it — vanilla JS support is pretty high up on our list
dboreham
Because nothing was already called "stack"?
seper8
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...

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

xzel
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?
WolfOliver
What would be the benefit of using Stack compared to one of the existing OpenId Connect Providers like Auth0, Okta, Keycloak, Ory... ?
roamerz
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?
mooreds
Upvoted for the pun. Nice one.
prng2021
Can you summarize what differentiates this from Supabase and Supertokens?
zaishi
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

Lucasoato
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.
spxneo
Would love to see compatibility with existing Clerk integration! Then I could stop paying Clerk and pay you haha

will it adapt to PrimeReact

n2d4
No PrimeReact yet, but won't be too hard to implement
fayazara
I was literally discussing why a service like clerk should be open source a few days ago. This is such perfect timing.
johndevor
Looks great. Would love a redwood integration!
awinter-py
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

booi
Auth is not a simple thing to do especially with the numerous accepted methods. Is there something that you think keycloak could do better?
mickael-kerjean
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
KronisLV
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!

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

[deleted]
(comment deleted)
ohans
> 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

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

ohans
No qualms! Congrats on the launch again
sneak
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.
zzzzzzzzzz10
What would be a standout feature compared to other open source authN/authZ solutions like Ory or Keycloak?
n2d4
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.
alexashka
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?
getcrunk
People want frameworks or standalone servers, probably driven by the web dev crowd wanting to only focus on product (shamefully, myself included)
catapart
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.

cco
We support any stack via our API over here at Stytch, take a look! Would love to hear feedback.
catapart
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.

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

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

Any plans to create components for Flutter?

n2d4
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 :)
jbk
What I really want is the next step: the one where it manages user groups and roles. :)
mooreds
Do you mean full user management? Via a UI or API? Or something else?
claytongulick
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.

Peer_Rich
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)
John23832
My first thought is why not supabase?