hckrnws

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

To quote myself from another comment chain:

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

YC does an 'open source panel' every batch where people come to hear from founders of successful open-source startups in order to learn the ropes. I've attended 4 of those by now (I think), so I have a sense of what gets said about this stuff from within the YC space at least.

I haven't heard anyone talk about ways to "pay-wall necessary features" or otherwise exploit users into paying. On the contrary, there's a lot of talk about how critical it is to be transparent and fair with your community. The consensus is that things tend to go well if you do that and badly if you don't.

The focus for these open-source companies is finding a natural way to carve out the free vs. paid parts of the space. By 'natural' I mean something that is a good fit for the domain and that both sides feel is fair. The free users know it's in their interest for the company to make money because that's how the whole thing is sustainable. People just need to feel that the paid product is one that it makes sense to charge for and that it's a fair exchange.

The most common way to do this is to open-source the product and offer a paid cloud offering. There are other approaches which I remember I found rather interesting, but unfortunately I forget the details because thanks to HN I never remember anything anymore!

But the main thing is no, not only are these founders not looking for ways to screw their open-source users, the seasoned ones are advising the junior ones to shy away from the slightest trace of that. The model by which an open-source company is making money needs to be as transparent and unimpeachable as possible.

One downside is that it's hard to get this right from the beginning, and changes can be messy. From what I've heard, the consensus is that if you keep a good relationship with your community at every step, and preserve transparency as an invariant, then it's at least possible to explain why a change is necessary and get through a messy phase that way.

While I do take your word very seriously and believe it’s 100% honest, it seems incongruent with most things I’ve seen and experienced over the last decade or so. There’s to me a very real crisis or at least dilemma for businesses that would love to do FOSS but can’t or won’t for unfortunate reasons.

Products are frequently over-complicated so self-hosting is difficult. There are often outright rug-pulls or dark patterns, keeping basic features behind their cloud offerings. The mega corps sometimes swoop in and take all the candy from the kids. Products are designed suboptimally, eg kubernetes native when they would be much better as a library. Then you have honest well meaning players who lose customers to self-hosting, because they need on-prem for security reasons, or simply because they want better debugging and logs.

Some varied examples off the top of my head include Docker, Hasura, Redis, Hashicorp, Benthos. My point here is combining small-medium sized businesses with a core FOSS product is full of perils, risk and unhealthy market dynamics. I’d assume the iceberg is also much bigger than these prolific projects, from companies that chose not to do FOSS in the first place.

You should evaluate the FOSS software features AS IS and ask if you're okay with the current feature set if all future features are behind an "enterprise" tier. If you are, and the hosting of the current version is manageable, then the product is good for both sides. I've often found running the numbers for paying the vendor for cloud vs amortizing devOps costs comes out in favor of the cloud version. I see this as a win-win for both the customer and the company.

I think COSS is great, it makes the code more secure and auditable and makes sure the developers get paid to fix security vulnerabilities. Volunteer OSS is great in theory but it sometimes leads to overworked developers being exploited by foreign intelligence services https://www.techrepublic.com/article/xz-backdoor-linux/. Supabase & Nextjs are part of the so called VC backed open source and they are great.

My opinion is that Supabase is one of the best models for OSS business we have seen. Do they get everything right? No, but they embody the spirit and adjust slot based on community feedback.

Vercel on the other hand, not so much. They’re closing the loop on multiple open source avenues and have been making features Vercel hosted only for awhile now. It’s getting harder and harder to properly and easily self-host Next.js for example.

> 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

I wrote a blog post that touches on this tangentially: https://www.mooreds.com/wordpress/archives/3595

Even if they pay-wall necessary features (or are forced to by investors), the software can be forked.

Same here. I’d rather them be transparent with the price and just undercut them. Last ‘open source’ YC project I reviewed almost felt like a hidden trap paywall. If they could cut my bill in half I’d switch, there is no reason Auth0 should charge so much. On the contrary another YC project just cut their competitor pricing and we are using them.

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.

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.

Congrats 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 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 ?

First, incorporating Stack into your project is really easy if you use Next.js — literally just a single command:

    npx @stackframe/init-stack@latest

.

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, and JWTs should not be long-living

- Impersonation to debug users or do customer support early on

- A user dashboard for basic analytics & editing, saves you from having to build this yourself in Retool

- Email shenanigans — for example, some mail clients click verification links automatically to check them for spam and then even interact with the page

- User profiles and account settings pages

- OAuth access token management, if you ever want to access APIs on the user's behalf

- App-based 2FA with HOTP/TOTP — we don't actually have this yet, but should be released this week still

- Redirects, so users land back on the same page after they successfully logged in

- Teams, so you can segment your B2B clients

- Access permissions for your users

- and more stuff, every time I make this list it's slightly different

Nice list. You came well prepared.

    > Email shenanigans — for example, some mail clients click verification links automatically to check them for spam and then even interact with the page

Check for cookies. If they exist, we can continue like normal. If not, require user interaction (none of the spam filters we tested click buttons, but from what I could gather, one of them — Outlook — moves the mouse).

That is a good idea: Require interactivity. Even something very simple like: "Click this button to continue." Any human will click it immediately. A spam checker: Stumped.

identifying those clients and emails using it would make for some easy account take over using password resets.

what people smoke to do those features?

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.

Nice. Do you guys also provide all the UIs for permission management/roles/orgs such that I can just css it and bolt it on? That was always a major pain point for me. You still had to make all the user facing ui and integrate it.

Sorry, I'm very well versed in the authentication space, but after spending 10 minutes browsing the documentation i truly can't understand the architecture. There are no drawings, it just jumps straight to npx install or comparing itself to other solutions, assuming i know all of them.

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?

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

Curious. There are already many alternatives (some open source) to Auth0 such as Keycloak, Zitadel, SuperTokens, etc. What makes Stack Auth different in your opinion?

This exact set of problems is precisely what we're trying to solve. Reading this feels like great validation :)

This is a great HN anecdote. Can you share more about why Auth0 was frustrating? I would like to learn more.

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!

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.

I think the “developer friendly” critique is a fair one for Ory, especially Ory Keto, which I found to be an absolute nightmare to use. But as a dev I found SuperTokens really easy/nice to use.

Open core vs. full open source, fair.

I found Supertokens hellish to use because of their Singleton approach and the "recipes" whatever that is that makes searching the docs a mess and also the integration. Also find their react sdk is pretty bad but eh. The nodejs part however is pretty good and I like that most functions can be overridden

Hmm fair, I’ve mostly just compared it to Ory Keto, Keycloak and FusionAuth, and it was my favourite so far, was the easiest to use/quickest to integrate for me. But it’s definitely personal, and it’s also a space with a tonne of players, have only tried a handful!

Absolutely wild how many of these there are now! I feel like I'm reading an announcement like this every few weeks.

I think its a sign of a bubble

There's been a lot of actually useful things in this bubble it seems. Ive been truly inspired how much little tool-age has been popping up.

I feel like if you took a bunch of literally just that last month of show/launch/announce HN things one could wrap up a whole secure, scalable, promptable, fully formed stack thats just looking for some sort of content.

when you see crowding in one segment its always indicative of a looming recession

Curious, can you elaborate?

Congrats on the launch. What's your approach to security? I notice there's no mention of any penetration testing, no security policy, no responsible disclosure policy, no place to report security vulnerabilities.

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.

We added a security policy: https://github.com/stack-auth/stack/blob/dev/.github/SECURIT...

If it helps you, we delegate the most vulnerable parts of the application, such as OAuth, to lower-level frameworks — similar to the unmanaged auth libraries people use today. We are essentially a thick wrapper around those, to create a full-stack platform from primitives. (Of course, that doesn't mean the thick wrapper cannot be vulnerable, but it helps with some of the most hideous bugs.)

The point I disagree with is that building it yourself is better than delegating it to a third-party — at best, you can secure your auth against vulnerabilities you're aware of. Unfortunately, this fallacy keeps coming up, but generally it's the case that homebrew auth is not more secure than open-source libraries, nor is proprietary code.

Thanks for adding a security policy.

To be clear I'm certainly not suggesting people write their own auth from scratch. My point is more that even when using mature frameworks it's possible to miss necessary bits or accidentally cause vulnerabilities around the edges. My experience here is building auth on Django's built in auth system which is fantastic. The issue comes when you start customising session management (for real product use-cases!), without then understanding all the interactions between various flows. As we were using a framework in our application, fixing these sorts of issues was straightforward, however if we had used a third-party hosted application (even if running on our own infra), it would likely have been far harder to spot the issues and address them.

Understood. Thanks for clarifying :)

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.

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.

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

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.

I think a comparison table here would be better for you here, considering your target audience and all.

How are you different than ZITADEL specifically?

They’re open source (Apache 2.0), developer friendly (nice, documented API), and handles authorization and user management well.

[dead]

How does this compare to Ory Kratos, also an open source option - https://www.ory.sh/comparisons/ory-versus-auth0/

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.

Unless you have extensive experience in the auth space, the Ory documentation and ecosystem is utterly undecipherable.

Hi 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?

1: https://database.dev/pointsource/supabase_rbac

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.

Have you seen this? https://github.com/logto-io/logto

How does it compare?

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

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

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.

What’s your timeline look like on that fancy supabase connector?

Auth is literally the next thing I’m working on…

What is your 2FA story like? This is one of the things Auth0 locks behind expensive plans but is a day zero day need for me.

This is actually exactly what I've been working on right now — currently doing E2E tests. Should be done by this weekend! (And available on any plan.)

Would be interested to hear a comparison with keycloak.

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.

I'm also surprised with the lack of mention of keycloak. It's been great to work with, and immediately curious how it would compare.

It's heavy weight and has an industrial vibe, and does way more than any single user could want. Consumes 300M or so just to run.

I don't care. Transaction volumes to the auth are comparatively low and computers are cheap so keycloak is a good choice.

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. We are not really looking to replace those use cases.

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?

Can you explain the example in the docs?

    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.

You're right. Thanks, fixed!

Can I have my own user database table without setting up web hooks?

Not right now, but we're working on a native Postgres extension as part of our Supabase integration — which would let you do that.

Congrats for the launch! We also launched an open sources (Apache 2 licensed) auth0 alternatives with paid hosting / enterprise support as revenue few years ago. Glad to see more efforts to help make software more secure for consumers!

https://github.com/authgear/authgear-server

i tried to use it & kept getting stuck! so turned to Clerk, which was easier to integrate

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!

Sorry about that! Can you send me an email with your package.json to konsti(at)stack-auth.com? Would love to try reproducing this.

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.

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

This post is not only terrible but also 5 years old. Web components are far from somewhat immature. Svelte is immature.

I started to integrate with WorkOS recently. I have an auth server that uses WorkOS for the authentication and then my auth server handles refreshing the access token etc with the client. It can also handle multiple clients.

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.

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?

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.

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?

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.

That looks good, specially pricing wise all the existing tools are simply unaffordable for B2C platforms where the majority of your users are not paying but you have to foot a massive Auth bill for then...

We use Ory right now, but it is very hard to setup and integrate into.

I see you're using bcrypt for now with a salt cost of 10. How do you plan to: 1. Make sure you keep increasing the cost over time 1a. Maybe even newer algorithms 2. Update old password hashes, even if the user does not log in

Some people much smarter than me have written excellent articles about this topic: https://www.michalspacek.com/upgrading-existing-password-has...

You passed my test :) that's the one thing I usually see skipped over with new auth solutions

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?

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.

Is it possible for the OAuth callback url to be self-hosted on a free/OSS plan too? otherwise it would allow the cloud hosted app to intercept the token exchange flow of a client credential grant, wouldn’t it?

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?

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

Does adding the Next SDK require every page to be server rendered? Can they still be statically cached and auth loaded only on the client?

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.

Congratulations on the launch! The UX already feels like such a breath of fresh air compared to the other solutions we've tried out. Can already see this adding so much value for us, and super excited to try it out!

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.

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?

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.

Makes sense. Yep, we can support that — just shoot me a message if you end up needing this (konsti (at) stack-auth.com).

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.

Thanks for mentioning FusionAuth, Theo.

For anyone curious about his experience or other folks experience, we have a series of interviews on our blog here:

https://fusionauth.io/blog/tag/community-story/

Here's the Switchboard post: https://fusionauth.io/blog/switchboard-reduced-migration-tim...

I’ve used FusionAuth as well and found it to be quite good.

As someone battling with Auth0's various broken integrations this sounds great.

Any idea how easy it is to use with PGP / Symfony?

Also, cheeky wishlist request, any support for Mastodon logins?

Can I enable the social login with this tool directly, without manually creating and setting up the "app"/"project" on those social platforms?

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

It's nice to have some trial quota.

Is it possible to automate the setup process ?

how does this compare to keycloak and supertokens?

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?

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)

Amazing. Good luck with the project, I’ll be giving it a test run soon!

Auth0 is the same with MFA pricing, absolutely ridiculous.

I'm integrating Zitadel right now (also open-source but with a paid hosted version) - how would you compare?

Any comparisons to Propel Auth? (Another YC funded auth service that seems to have lot of overlap here)

That looks interesting, but also expensive.

I was sceptical but your responses so far may have won me over.

Are you planning on implementing passkeys at all?

Heya, congrats on launch! Welcome to the authN/authZ/user management party!

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!

What does dual licensing AGPL/MIT do? Isn’t the MIT license more permissive in all cases?

Our clients are MIT, our servers are AGPL.

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])

AGPL is fully open source, and definitely allows you to host it without open sourcing anything of your code. That's one of the very freedoms that the open source definition contains.

Calling the AGPL not open source is crazy

Yes, this was my misunderstanding of the AGPL license. Makes sense now.

Looks nice! How is it different from other well-known projects, like Ory and Logto?

If ever there was a case for OSS M&A it would be this project merging with auth.js

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!

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

> frustration with the incumbents

That's to say the least.

Do you guys only offer SAML in your hosted SaaS?

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.

Ah gotcha, that's a nice way of approaching it. Best of luck to you guys.

Reminds me of ory project

huge congrats on the launch! Auth can be a huge pain...

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.

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.

Cofounder of Clerk here - we definitely want free plan users to be aware of this limitation - any suggestions to improve visibility?

On https://clerk.com/pricing , “Customizable session duration” is listed as a primary benefit of the pro plan, and in the chart we show that the free plan is “Fixed to 7 days”

Apologies we failed to make it clear before you started, that’s definitely not intended. We thought this was a good limitation for the free plan because it doesn’t impact your ability to learn if your product is resonating. If it is, and our default doesn’t work for your app, then we hope you can upgrade now that your product is validated. (It’s maybe worth mentioning that the default of 7 days was selected by copying Google’s session lifetime, also not meant to be nefarious.)

What did you migrate to instead?

I went for NextAuth - the use case was relatively simple, and I wanted maximum control.

Ehh I actually don’t think that’s that bad — they do have to run a business! What limitation would work better on the free tier?

This came up on Reddit and the founder responded directly there, seemed like they were going to add a tool tip or something to make it clearer.

> 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?

You must encrypt and salt passwords and retrieve them without being susceptible to timing attacks. PKCE. 2FA/TOTP as well.

Those are traditionally done with existing proven solutions, not "rolling your own crypto" though.

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

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.

[dead]

Could be simplified: "Sign in using NSA services"

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

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

Alright sir! I may have a look with my current nextjs project.