Live data from Hacker News

Ask HN: What do you use to build auth?

news.ycombinator.com

21–30 of 141 posts

Re: Ask HN: What do you use to build auth?

#22

If I want to put something together fast I use the default AWS Cognito and Firebase Auth widgets. I think Firebase Auth has more third party sign in options. In my current project I do away with accounts completely and just email a link that sets a cookie for 30 or 90 days [1]. I think the Auth you choose highly depends on the money/privacy/sensitivity/fraud potential of your project. [1] https://tedpiotrowski.svbtle…

Absolutely recommend against using AWS Cognito. It is a nightmare to use. Currently I am trying to integrate Firebase into AWS because of how bad Cognito is. One thing going well that Cognito will never be is Firebase Auth.

+1 That's one product AWS completely dropped the ball. Also, it has not received relevant updates for a long time.

Re: Ask HN: What do you use to build auth?

#24

If I want to put something together fast I use the default AWS Cognito and Firebase Auth widgets. I think Firebase Auth has more third party sign in options. In my current project I do away with accounts completely and just email a link that sets a cookie for 30 or 90 days [1]. I think the Auth you choose highly depends on the money/privacy/sensitivity/fraud potential of your project. [1] https://tedpiotrowski.svbtle…

Absolutely recommend against using AWS Cognito. It is a nightmare to use. Currently I am trying to integrate Firebase into AWS because of how bad Cognito is. One thing going well that Cognito will never be is Firebase Auth.

What made it a nightmare to use? We're just about finished migrating to Cognito (using our own UI) and it's been the same experience as working with Auth0 but much cheaper. The only goofy part was in order to have a custom password reset email you need to put it in a lambda.

Re: Ask HN: What do you use to build auth?

#25
post #19

I too have seen the articles proclaiming that devs should stop implementing auth themselves and instead use some Auth as a service product. After all Authentication is hard to get right, right? Actually the basics are really easy. Using a short-term JWT and bcrypt to salt passwords is like maybe 10 lines of code. The thing is, most of the truly hard Auth problems I've had to solve in my career took a highly custom ap…

> Using a short-term JWT and bcrypt to salt passwords is like maybe 10 lines of code.

You are presenting an extremely limited scope.

What you get from using an authentication provider is things like verifying email addresses, OAuth where you just have to "enable" Google, Github, Apple login possibilities. Implementing all these flows yourself is a lot more than 10 lines of code.

Then you also have to do password reset flows, resent email confirmation emails etc.

Re: Ask HN: What do you use to build auth?

#26
post #19

I too have seen the articles proclaiming that devs should stop implementing auth themselves and instead use some Auth as a service product. After all Authentication is hard to get right, right? Actually the basics are really easy. Using a short-term JWT and bcrypt to salt passwords is like maybe 10 lines of code. The thing is, most of the truly hard Auth problems I've had to solve in my career took a highly custom ap…

Devs should never default to using JWTs IMO, I think that is leading folks to delegate auth to providers as it overly complicates the process. There's nothing wrong with stateful API keys/session tokens, and I would wager the majority of web services still use them.

Re: Ask HN: What do you use to build auth?

#27
For most projects these days I will use a provider for two reasons:

1. Easy to implement 2. The burden of security is moved.

I use clerk.dev for almost any project at this point. They take care of auth/ authorization/ database sync.

Sure I could implement these on my own but why not use SSR for next and hook in and have everything setup in minutes so I can focus on the rest of the app that matters more.

Re: Ask HN: What do you use to build auth?

#29

If I want to put something together fast I use the default AWS Cognito and Firebase Auth widgets. I think Firebase Auth has more third party sign in options. In my current project I do away with accounts completely and just email a link that sets a cookie for 30 or 90 days [1]. I think the Auth you choose highly depends on the money/privacy/sensitivity/fraud potential of your project. [1] https://tedpiotrowski.svbtle…

Absolutely recommend against using AWS Cognito. It is a nightmare to use. Currently I am trying to integrate Firebase into AWS because of how bad Cognito is. One thing going well that Cognito will never be is Firebase Auth.

You're right. Things I don't like about Cognito is it stores your users email address/phone number but limits additional metadata so you need a separate user DB table. Now you have to keep Cognito and your user DB table synced and if you want to display a users email along with mailing address, etc on a page you have to query both Cognito and your user DB.

The ease of two factor Auth is nice though.

Post reply on HN