Ask HN: What do you use to build auth?

Wrestling with this now for a side project. I've landed on .NETCore+ASP.NET Identity after getting frustrated with NuxtJS+fastify-auth, but that's really because I'm more familiar from my day job and didn't like the SPA road Nuxt was forcing me down.

That said, I have a related question I'm hoping the security nerds here can help with: I know it's bad practice to reveal the existence of an account during registration, because it gives an attacker a way to know if a user has an account. So on registration, if the email already exists on another account, you shouldn't say "that account already exists" or do anything that would reveal the account already exists. To me, that means you should always send the user to a "registration successful, check your email" page and then if they already exist, send an email saying it exists with links to password reset & login. That means that the app must be unusable until the user validates their email. But that seems annoying and is not what many sites do. For example, I just tried on shopify, and if the account already exists, they send you to the login page. If not, they log you in automatically. So, for shopify I could in theory scrape using a email list and find who has accounts. To see why this is bad, think of shadier sites (my saas is not). So, my main question: am I making too big a deal about this security requirement or the usability problem it presents? Am I missing some alternative?

Related, I'm thinking about letting users send an email to bot@mysaas.com or text 5558675309, which would respond with a "finish registration" or "login" page and auth token accordingly. This would let them skip the verify email step. Is this a bad approach?

said it before, but I love magic links. One more site where I dont have to create an username/password (and yes its a hassle, even with a password manager)

I’ve been tinkering in this space for about a year now. They all have their own problems.

- NextAuth is bare basic but gets you going real fast. The most examples - both simple and complex - and works with so many DB adapters.

- Clerk was probably the nicest developer experience: fast, works with many frameworks, and great community. But there’s not a lot of support outside of basic examples.

- Supabase Auth is a little more mature than Clerk and ultimately what I ended up choosing. But it doesn’t have the out of box features: orgs, different environments, MFA.

As I said, landed on Supabase for the application database. It makes a lot of sense and works great.

Hi! Disclaimer, I'm the co-founder/cto at Stytch[0]. We built Stytch because we went through the pain of building auth both in house and with incumbent players and wanted a better tool for developers building authentication. Stytch is flexible to enable you to build the experience that you want for your users but we do all the heavy lifting when it comes to both authentication and authorization.

We have support for both magic links and google oauth as well as many more options, one of the benefits of going with a provider is that with one integration you'll be able to get more auth products as your auth needs expand and get more complex (ie 2fa with authenticator apps etc). We also handle all of the fun edge cases when it comes to things like email deliverability and ensuring that your magic links end up in your users primary inbox and don't get blocked by spam filters etc.

I'd love to answer any questions you have and help get you up and running with auth so you can get back to focusing on your product!

[0] https://stytch.com/

Authentication systems are the most common thing to have security related bugs?

I'm shocked.

FWIW, the majority of things on that list aren't what I'd consider covered by any auth library I know of.

It's mostly people just not using their authentication, diy or not.