[psankar]

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 ?

[n2d4]

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

[throwaway2037]

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

What is the technical workaround for this issue? Do you check user agent?

[n2d4]

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

[throwaway2037]

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.

[1oooqooq]

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?

[cpursley]

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.

[nwellinghoff]

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.