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!
Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative
111–120 of 146 posts
Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative
#112Congrats 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 a…
First, incorporating Stack into your project is really easy if you use Next.js — literally just a single command: npx @stackframe/init-stack@latest If you use our managed hosting, we'll deal with deployment, backup, ... for you. . 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,…
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.
Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative
#113How 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!
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.
Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative
#114Any comparisons to Propel Auth? (Another YC funded auth service that seems to have lot of overlap here)
Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative
#115Hi 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?
Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative
#116Hi 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…
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.
Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative
#117Would be interested to hear a comparison with keycloak.
Keycloak is a pain to set up, and its configuration tends to get quite messy — besides, we try to cover integrations into the entire stack (frontend to the database). 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.…
Keycloak, while complex, doesn't feel overly complex. It exposes the complexity of the auth space to you.
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?
Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative
#118> frustration with the incumbents
That's to say the least.
Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative
#119Hmm. 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.
[deleted]
Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative
#120Auth is the biggest headache of starting a new project. From your Github README, this looks pretty awesome! 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.
Unfortunately, Web Components are still somewhat immature [1], but eventually, our plan is to support vanilla React as well. We really want to nail every single integration that we officially support before growing horizontally, because looking at some of our competitors, often its greatest failures come from rushing framework support. So, we went with the most popular JS framework first (Next.js), and are gonna go f…
This post is not only terrible but also 5 years old. Web components are far from somewhat immature. Svelte is immature.