stack VS auth

Hi HN! 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.

You can find our customer pitch elsewhere, so instead I'll tell you more about us and the company. We are developers building for other developers, so you can think of everyone here as a devX engineer. We launched with a Show HN in April, and have been growing exponentially since.

Think of us as a fast-moving open-source infrastructure business. We spend a lot of time thinking about how we can maintain the agility of a startup while being as reliable as incumbents. Sometimes, this means new ideas; for example, we heavily rely on AI and snapshots for our E2E tests, and have API migration tooling that blows everyone else out of the water. If you have ideas like these, we want you.

We've sworn to keep a no-bullshit culture. We're all pulling on the same string; we don't keep secrets from each other and always assume good faith. We want to build the open-source cloud infrastructure of the future; we'd rather die trying than sell out for a quick buck.

We are (very) well-funded by investors such as YC, Paul Graham, Guillermo Rauch, Theo Browne, and Khosla Ventures. Our number one priority is to build an outstanding product that developers *really* love — everything else comes second.

For now, we are exclusively hiring onsite in San Francisco; sadly, we don't currently have any remote positions. Optionally, you can move with us into our hacker house (both temporarily or permanent), but you can live in your own home too.

If that sounds like a great fit, email me mentioning that you're from HN and tell me why we caught your eye: konsti (at) stack-auth.com

Thanks all!

I'm biased but Stack Auth [0] is fully open-source, self-hostable, and we offer reasonably priced managed hosting, if that floats your boat.

[0] https://github.com/stack-auth/stack

Stack Auth maintainer here. Kinda disappointed by the lack of open-source solutions in this thread — if anyone's looking for managed auth like WorkOS/Clerk/Auth0, but wants it to be 100% open-source, you should give us a go. https://github.com/stack-auth/stack

Before we dive in, I want to quickly introduce Stack Auth, the open-source authentication library we’re building. It’s designed to be super easy to set up and offers a beautiful set of UI components right out of the box! Whether you’re building a SaaS product or your next side project, Stack Auth simplifies authentication without compromising on flexibility.

Not sure about Azure ecosystem but huge fan of https://clerk.com/.

Trying out https://stack-auth.com/ which just launched on HN, mostly out of OSS solidarity

We created a SECURITY.md file on our repo, it's in the .github folder: 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.

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.

If you choose the latter, there's absolutely no reliance on us; if you think we're doing a bad job at any point in time, you can export all your data and start self-hosting instead.

Also, we're more than just authentication — we have authorization built-in (permissions, teams, ...), and a frontend to manage your users (with impersonation, filtering, ...). You can use any language to access these features through our REST API [1].

We also have a bunch of components for sign in, password reset, organizations. For now, we only support Next.js frontends and backends in any language with our REST API [1], though our docs also list the client endpoints, and some people have been building frontends for other languages.

For more info, check out our GitHub repo. We're really early, but have a handful of production users already. Any feedback is highly appreciated!

Thanks all!

[0] https://stack-auth.com

[1] https://docs.stack-auth.com/rest-api/auth

[2] https://github.com/stack-auth/stack

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

Supabase Auth now supports anonymous sign-ins, one of our most-requested features by the community.

People keep writing this, doesn't Supabase rely on spinning up additional services to leave, meaning you can't leave to another managed offering?

Off the top of my mind, PostgREST and go-true? https://github.com/supabase/auth

-

If you use Postgres you're "locked" into Postgres: a technology with a laundry list of providers.

If you leave Supabase, you'll lose the fully managed aspect of 99% of the Postgres providers out there, which confirms the pain the parent comment is describing.

> Microsoft scans to check the website contains malware. IMHO the security blunder is a self-implemented magic link.

It's not self-implemented, you can check it out here: https://github.com/supabase/gotrue

> Not password protected if the password is part of the URL.

It's a token that's valid for a couple of minutes – just like a password reset token. Indeed, in the given implementation, it's the very same as the password reset token. If you consider this implementation as "not password protected", any website with a password reset functionality is "not password protected".

I hate to be this guy, really. I would like to adopt Supabase in company, but I cannot yet.

I commented on a HN post almost a year ago about how hard is to do custom Auth with Supabase. I still haven't find a good solution about it. For example, LDAP Auth is quite crucial in most enterprise settings, yet I have no idea how to do it with Supabase. I can find a workaround for PostgREST by putting a secondary API written in some other language and fiddling with reverse proxies. But how to do with Supabase, such that all other services (realtime,...) works nicely? Is it so hard to provide a function that accept a custom strategy given the HTTP request data?

I created an issue[0] almost a year ago on Supabase, which was transferred to Gotrue. I even provided some code examples from Laravel. Even if it is not specifically for LDAP, make some API available to do so, please.

[0] https://github.com/supabase/gotrue/issues/904

Yes there is, it's just not pretty yet: https://github.com/supabase/gotrue/blob/master/openapi.yaml

The gotrue api: https://github.com/supabase/gotrue

Validation happen inside of the GoTrue: https://github.com/supabase/gotrue... but you don't need it on your own, non supabase, server side resources... that's the beauty of JWT. You can validate JWT in any back-end / language, by simply checking the signature against HS256 key.