Live data from Hacker News

Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative

github.com

71–80 of 146 posts

Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative

#71
post #66
post #48

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

Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative

#72
post #33

Earlier quoted context omitted.

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.

Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative

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

Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative

#75

Earlier quoted context omitted.

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

Calling the AGPL not open source is crazy

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

Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative

#78
post #54
post #51

Earlier quoted context omitted.

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.

What did you migrate to instead?

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

Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative

#79
post #76

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

Re: Launch HN: Stack Auth (YC S24) – An Open-Source Auth0/Clerk Alternative

#80
post #74

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

Post reply on HN