Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What do you use to build auth?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 141 posts

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

#91

Post by x1xx »

dewey wrote: post #25
jaeming wrote: 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 rese…

also password policies, account takeover detection/prevention, user device/session list management

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

#92

Post by kiwicopple »

johnbellone wrote: post #55

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 lit…

MFA is close - aiming for our next Launch Week in August

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

#93

Post by aristofun »

I bet just passport js with its many strategies is a good enough option for 98% of SaaS startups out there.

It’s not a rocket science unless you’re big enough to bother about tricky use cases and unique security requirements.

Despite what Auth providers are trying to promote.

PS: I mean authentication only. Authorization seems like a different beast with different challenges, sometimes tightly coupled with your business logic.

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

#94

Post by quaffapint »

tppiotrowski wrote: post #75
quaffapint wrote: post #24

Earlier quoted context omitted.

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.

Attributes. There are standard attributes like email, phone_number, name, address. Then there are up to 50 custom attributes you can define which need a min/max length and can be of number or string type. You can't remove or change them after you define them. As you user metadata grows this can be insufficient and inflexible causing you to store user data set in another place like a DB. Now your user data is fragment…

Ok, good to know. We've always used our IdP as bare bones as possible and store all user info locally in the DB, so that's why this wouldn't be an issue for our particular setup.

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

#96

Post by WorldMaker »

jaeming wrote: 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…

There's an old adage: If you think auth is easy to write, you probably don't know auth.

I obviously don't know how much it compares to your specific case, but as general advice it's often good advice when phrased less antagonistically: don't roll it yourself because the rabbit hole is deeper than you expect.

On that front, you may think you are paranoid enough, but keep in mind that the service products sometimes have a multiplier effect in play: N developers of various levels of paranoia, M people in various ops/InfoSec/auditing roles, X committees/layers designed to minimize corporate security risk.

If auth isn't your job and isn't your core competency, many times it is worth asking if following the rabbit down the hole is worth the time you could save outsourcing to a multiplier effect of a team that focuses 100% on those tasks. As with most "buy versus build" discussions, it's not just about "comfort" but leveraging those multiplier effects. Can you pay someone else for the years of experience and "rabbit hole wandering" and multiple layers of security audits? Auth is a "must have" feature for most products but in and of itself is mostly a security liability and mostly pure overhead: no customer is paying you directly for your auth features, auth is the annoying hurdle to features that they do care about and will pay you for. All that time spent on auth and auth security audits rarely appear to provide good returns on investment for your product and your customers. Time spent on auth is time wasted from user-facing features.

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

#97

Post by WorldMaker »

mg wrote: post #44

From a user perspective, how does everyone here feel about magic links vs email and password? Personally, I am torn. As a developer, magic links are awesome. You put a new project online, and everyone on planet earth already is a user. Well everyone who has an email. But from a user perspective, it is more cumbersome. For one because the switch between email and website. And because the typical magic link implementat…

There are users out there (likely even people that you know, because statistically it's a lot of people) that habitually never remember passwords and their login flow is almost always "Click Forgot Password, Enter Email, Receive Email, Click Link, Enter new Password they also won't remember" so from that perspective magic link flows save at least two steps!

Even power users that have trained themselves to use a password manager generally have more steps than they think they do to open the password manager, enter master passphrase/biometrics/etc, copy and paste the password.

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

#98

Post by dickhardt »

joshxyz wrote: post #89
dickhardt wrote: post #87

Your question is missing a couple key inputs. Q: Is your SaaS app targeting enterprise use cases, where the customer will want to enable SSO and centralized provisioning? Keybase is a reasonable choice in this case because of the SAML and SCIM support. Q: What is your expected revenue per user? Auth0 solves many problems out of the box, but is priced on MAU which can be prohibitive if your revenue per user is low, bu…

I think you meant KeyCloak not Keybase? haha.

I did!

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

#100

Post by rtev »

jaeming wrote: 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…

In your “should I..”s, you mention implementing multiple insecure approaches. If you’re implementing sessions tied to localstorage, your application has a medium severity vulnerability. If you’re improperly invalidating, that’s yet another medium severity vulnerability.

The problem is, you’ll slip up here and there. The experts recommend not rolling your own for a reason; little mistakes and gotchas like the details in your post can lead to significant compromise.

Post reply on HN