[HN Gopher] Launch HN: Stack Auth (YC S24) - An Open-Source Auth...
___________________________________________________________________
Launch HN: Stack Auth (YC S24) - An Open-Source Auth0/Clerk
Alternative
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!
Author : n2d4
Score : 108 points
Date : 2024-08-08 18:23 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| floydnoel wrote:
| wow, I've been waiting for a project like this! Clerk seems fine,
| Auth0 is fine, but I'd rather build on open-source. Can't wait to
| start integrating this into my next project
| telesilla wrote:
| How does this compare to Ory Kratos, also an open source option -
| https://www.ory.sh/comparisons/ory-versus-auth0/
| n2d4 wrote:
| Kratos is geared towards enterprises and less developer-
| friendly. We integrate very closely into the tech stack that we
| currently target, which is Next.js + Postgres, and want to make
| setup as straight-forward as possible.
|
| I would say we are to Ory what Clerk is to Auth0.
| candiddevmike wrote:
| I don't think your differentiators are enough for folks to pull
| the trigger on something like this. There are a ton of folks in
| the space--supabase, supertokens, ory to name a few, not
| including the cloud providers who offer this service as well--how
| do you differentiate yourself from them?
| n2d4 wrote:
| Supabase Auth: We do much more than them -- e-mails,
| organizations, permissions & RBAC, user dashboard,
| impersonation are some of the features we have. (I like
| Supabase a lot as a DB -- we're working on some fancy
| connectors to use Stack Auth alongside Supabase RLS, so you can
| get the best of both worlds.)
|
| 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.
| treve wrote:
| Absolutely wild how many of these there are now! I feel like I'm
| reading an announcement like this every few weeks.
| localfirst wrote:
| I think its a sign of a bubble
| mmcclure wrote:
| Looks nice, congratulations on the launch!
|
| 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.
| n2d4 wrote:
| In theory yes -- actually, we already are an OAuth provider
| behind the scenes -- though we haven't documented this anywhere
| yet. What would you use it for?
| mmcclure wrote:
| If I'm going to reach for a 3rd party auth provider like
| this, I want to be able to use it across all of my potential
| properties. For example a Discourse forum, or a Shopify
| store, etc.
| n2d4 wrote:
| Makes sense. Yep, we can support that -- just shoot me a
| message if you end up needing this (konsti (at) stack-
| auth.com).
| esafak wrote:
| I'd suggest preparing a comparison table on the home page, at
| least against open source competitors, to help prospects decide.
| You emphasize completeness (authz + authn), and simplicity here:
| 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.
|
| Your pricing seems multi-tenant friendly. What other
| differentiating factors can you think of?
| n2d4 wrote:
| Appreciate the feedback! We have the following in our GitHub
| README, which we should probably copy to our frontpage:
| > # How is this different from X? > > Ask
| yourself about X: > > - Is X open-source?
| > > - Is X developer-friendly, well-documented, and
| lets you get started in minutes? > > - Besides
| authentication, does X also do authorization and user
| management (see feature list below)? > > If you
| answered "no" to any of these questions, then that's how Stack
| Auth is different from X.
| esafak wrote:
| If you want to be developer friendly, create examples for as
| many languages as you can, and include them in the
| documentation, and as GitHub repos. Don't say "it's REST,
| DIY!"
| n2d4 wrote:
| Noted, thanks. We're focussing on Next.js frontends right
| now -- which is fairly well-documented -- I hope to get
| some Python & Golang examples in there by the end of the
| week.
| rudasn wrote:
| I think a comparison table here would be better for you here,
| considering your target audience and all.
| kamikazeturtles wrote:
| Auth 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.
| n2d4 wrote:
| 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 from there once we're confident in it.
|
| [1] https://dev.to/richharris/why-i-don-t-use-web-
| components-2ci...
| codingwagie wrote:
| Auth doesnt need a new service/company. It needs an ai chatbot
| that walks engineers through adding auth to their project. Its
| the developer experience that is the problem
| n2d4 wrote:
| You might like what we built then -- we have a setup wizard
| that adds auth to your Next.js project for you, including
| creating all the necessary pages, handlers, and config ;)
| npx @stackframe/init-stack@latest
| codingwagie wrote:
| Alright sir! I may have a look with my current nextjs
| project.
| paulirwin wrote:
| Congrats on the launch! This looks great.
|
| 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?
| n2d4 wrote:
| Yes. 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.
| nobleach wrote:
| I notice you're mentioning: "We support Next.js frontends" and
| "Idiomatic Next.js APIs". What is it about your product that is
| NextJS specific? Can someone who has no interest in using NextJS
| still use your product?
| rsyring wrote:
| From the OP:
|
| > 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.
| n2d4 wrote:
| Our backend and dashboard are language-agnostic, and you can
| access their REST API from anywhere. However, there is a
| Next.js SDK with server & client components, hooks, and
| functions that integrate very deeply into the framework -- that
| one is Next.js-only.
|
| 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: npx
| @stackframe/init-stack@latest
| theogravity wrote:
| As someone who came from Auth0 and god-awful Amazon Cognito,
| we've been using FusionAuth for years. Their APIs and SDKs have
| been amazing to work with.
|
| 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.
| ftlio wrote:
| I've used FusionAuth as well and found it to be quite good.
| msoad wrote:
| Can I have my own user database table without setting up web
| hooks?
| rudasn wrote:
| This looks very refreshing! Congrats for officially launching,I
| think StackAuth was mentioned here before.
|
| 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.
| n2d4 wrote:
| Indeed, we launched an MVP in Show HN a few months ago -- dang
| messaged us and said we should apply to YC, which we did, and
| now we're launching here again, officially. :D
|
| 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.
| hoofhearted wrote:
| This is pretty awesome and well encompassing for basic
| authentication!
|
| 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!
| jay-barronville wrote:
| This is really awesome. On almost every project I've worked on,
| I've never been able to trust and truly rely on proprietary
| services and companies to handle my authentication and
| authorization. I've been forced (i.e., it was already decided) to
| use Auth0 before and I hated every minute of it.
|
| Congratulations on launching Stack Auth and providing a better
| alternative!!!
| n2d4 wrote:
| This exact set of problems is precisely what we're trying to
| solve. Reading this feels like great validation :)
| nilsbunger wrote:
| What does dual licensing AGPL/MIT do? Isn't the MIT license more
| permissive in all cases?
| n2d4 wrote:
| Our clients are MIT, our servers are AGPL.
| sha_r_roh wrote:
| Just for clarification, So you can't really host this without
| open-sourcing my product (since your server is AGPL). Isn't
| it a stretch to call this really open-source? I compare this
| to something like a temporal which I can self-host without
| worrying (and which I believe is MIT license
| [https://github.com/temporalio/temporal/blob/main/LICENSE])
| abraae wrote:
| Would be interested to hear a comparison with keycloak.
| june07 wrote:
| Surprisingly your the only one who has mentioned Keycloak so
| far?! I switched several projects from Auth0 to it some time
| ago and didn't look back... particularly when they started
| tightening things since said projects were not even profitable.
| no1youknowz wrote:
| This is great. Competition is definitely needed in the
| Authentication/Authorization space.
|
| 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
| n2d4 wrote:
| Supabase Auth is only authentication; it doesn't do
| organizations, permissions/RBAC, impersonation, etc. We are
| working on some fancy Postgres connectors to let you use Stack
| Auth with the DB part of Supabase and RLS.
|
| 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.
| hardwaresofton wrote:
| A bit of a meta point, but Clerk must be doing really well if
| they're already positioned as the thing to make alternatives to.
| luckyt wrote:
| Clerk has quite a few dark patterns in their free tier, eg: if
| your app is on Clerk free tier, all your users will be forced
| to log out and re-login every 7 days (and they try to obfuscate
| this fact until you're locked in). For this reason, I've
| recently had to migrate away from them - I'm really glad there
| are alternatives.
| grinich wrote:
| What did you migrate to instead?
| colinramsay wrote:
| I think Clerk looks great but it starts to get quite expensive if
| MFA is a requirement. Do you have 2FA/MFA in your roadmap?
| n2d4 wrote:
| I've literally been building this right now, currently doing
| E2E tests! Should be done by end of the week. (and it'll be
| free for everyone)
| colinramsay wrote:
| Amazing. Good luck with the project, I'll be giving it a test
| run soon!
| smashah wrote:
| If ever there was a case for OSS M&A it would be this project
| merging with auth.js
| Lord_Zero wrote:
| Have you seen this? https://github.com/logto-io/logto
|
| How does it compare?
| n2d4 wrote:
| Logto's focus is on enterprises, while ours is on the developer
| experience for startups and side projects. I've used this line
| in a few comments on this thread already but I'd say that Stack
| is to Logto what Clerk is to Auth0.
|
| (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.)
| tgma wrote:
| > _Rolling your own crypto is already hard enough_
|
| Wait, what? Do you role your crypto to handle standard auth
| flows? Is this some machine generated text?
| aabbcc1241 wrote:
| Can I enable the social login with this tool directly, without
| manually creating and setting up the "app"/"project" on those
| social platforms?
| n2d4 wrote:
| Yes.
|
| 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.)
| zinclozenge wrote:
| Do you guys only offer SAML in your hosted SaaS?
| n2d4 wrote:
| Everything is open-source.
|
| 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.
| localfirst wrote:
| how does this compare to Supabase Auth?
|
| 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
| n2d4 wrote:
| Supabase Auth is just authN, and it doesn't do authZ
| (organizations, permissions/RBAC) or user management
| (impersonation, user metadata, etc.). It also doesn't integrate
| as deeply into Next.js as we do.
|
| 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.
| Alupis wrote:
| Regarding managed hosting - I don't see a mention of using your
| own custom domain anywhere. Did I miss it? Which tiers can use
| custom domains, if they are supported?
|
| Also, do you support m2m tokens, ie. client credentials flow?
| What are the limits, if any?
| n2d4 wrote:
| Our approach to sign-in pages is a bit different than Auth0's;
| instead of redirecting you to us, all of our components live on
| your very own website. The only time the browser will redirect
| to our domain is momentarily during the OAuth callback. We also
| don't brand our components, so your users may never even see
| that you use us for auth.
___________________________________________________________________
(page generated 2024-08-08 23:00 UTC)