Live data from Hacker News

Three things to never build yourself: auth, notifications, payments

courier.com

61–70 of 193 posts

Re: Three things to never build yourself: auth, notifications, payments

#61

More general: Things to never build yourself: Things outside your core business. Are you selling a notification service? Build it yourself, otherwise find either self-hosted or hosted solutions, depending on situation.

There’s a huge range between doing everything yourself and handing your users to another company and make all of your business depend on an external SaaS provider‘s whims.

Re: Three things to never build yourself: auth, notifications, payments

#62
post #53

Earlier quoted context omitted.

> Never outsource Auth. Maintain control over user accounts. This is some of the worst advice I've ever seen on HN. Don't take on risk you don't understand and cannot afford to mitigate. Don't be the next Equifax.

It is really not difficult to use BCrypt or Argon2 with your backend of choice. Proper password and session management have been made accessible for many years if you use any "modern" backend.

It's true the happy path and common error cases are easy to account for. But it just takes one overlooked bug or vulnerability either in your code or a library's code to send it all crashing down.

Re: Three things to never build yourself: auth, notifications, payments

#63
post #15
post #5

Regarding auth, I absolutely bought to JWT cool-aid but honestly if you're still on the monolith phase just use the most popular auth framework for your language. JWT adds a lot of complexity and room for misconfiguration, you do get something in return of course - it is stateless (hence scalable), works great with microservices, and improves your security model somewhat by separating issuing from verification. But y…

To make things easy I usually use "alg":"none". It makes using jwts a breeze. https://datatracker.ietf.org/doc/html/rfc7518#section-3.6

Like a sibling comment said, hopefully this was tongue in cheek.

If you use "none", anyone can forge a JWT that says anything. I always say:

* You should have some other way of verifying that the JWT was unchanged by the client, like say being on a private network or using client TLS certs

and

* You should benchmark and know that the signing overhead is a significant source of performance degradation in your system.

Otherwise, sign your JWTs! :)

Re: Three things to never build yourself: auth, notifications, payments

#64
post #49

This is a biased article. I would not let another company handle authentication or notifications for my apps. Payments, yes.

It's kind of funny that you'd allow someone else to manage money, but you wouldn't let someone else manage something that has the potential to cost you an equal or greater amount of money in GDPR violation fees and lawsuits.

Exactly!

Re: Three things to never build yourself: auth, notifications, payments

#65

I’m biased but I would add: monitoring

Yes! I think that the benefits of an outsourced monitoring service are huge compared to the amount of money you pay.

There are also simple ones that you can get started with for free/cheap.

Re: Three things to never build yourself: auth, notifications, payments

#66

Never outsource Auth. Maintain control over user accounts. That's the life blood of your business. If you have to ask everyone to reset their password because your auth provider increases their pricing or goes out of business, the churn will likely kill your company. I would say the same for Stripe, but at least they'll help you migrate off their platform. Auth providers cant help you because the passwords are hashed…

Making people reset their password is not that big of a deal. I have run into this multiple times, the most recent being amtrak.com. It just told me "you have to reset your password" and I got a link in email like if I had forgotten it. I have also received many "we had a security incident you have to reset your password now" emails in recent years.

Re: Three things to never build yourself: auth, notifications, payments

#67

Never outsource Auth. Maintain control over user accounts. That's the life blood of your business. If you have to ask everyone to reset their password because your auth provider increases their pricing or goes out of business, the churn will likely kill your company. I would say the same for Stripe, but at least they'll help you migrate off their platform. Auth providers cant help you because the passwords are hashed…

> Never outsource Auth. Maintain control over user accounts. This is some of the worst advice I've ever seen on HN. Don't take on risk you don't understand and cannot afford to mitigate. Don't be the next Equifax.

I don't think the main problem with Equifax was the Auth info they lost. It was their own business data, e.g. social security numbers etc, which wouldn't have been outsourced to their Auth provider anyway.

Re: Three things to never build yourself: auth, notifications, payments

#68
post #36
post #16

Crap, I’ve done all three! Well, maybe not all at once though. I can see why not to do notifications, but it’s hard to avoid doing some form of it if you’re making an app with focus on low latency realtime updates. The bigger problem is that out of all three categories, I only really feel content with trusting Stripe, and only so much. Auth0 has its issues, and decent authentication systems you can roll on your own a…

I'm curious how people handled payments before Stripe? Did you integrate with banks directly? How different is that in terms of what Stripe offers?

We used CyberCash (I think) and Authorize.net, which were to Stripe as Altavista was to Google search.

That is to say that even 20 years ago there were middlemen in the payments space, they just were pretty horrendous to work with.

Re: Three things to never build yourself: auth, notifications, payments

#69
post #59

I agree with Payments (PCI-DSS hell) & Notifications (especially email & SMS), but Authentication? Fuck no. Unless there is a business requirement for sharing your authN scope with multiple external systems, you should not worry about plugging your app's auth into someone else's idea of a good time. Consuming external authentication providers like Active Directory is something we do today, but it barely registers as…

> Any time you take a problem that exists on one computer and spread it across many computers, it gets exponentially more difficult and prone to error.

Hard to argue with that.

Unfortunately sometimes you can't say "we have the single source of truth" about a user; federation exists for organizational reasons.

Re: Three things to never build yourself: auth, notifications, payments

#70

Never outsource Auth. Maintain control over user accounts. That's the life blood of your business. If you have to ask everyone to reset their password because your auth provider increases their pricing or goes out of business, the churn will likely kill your company. I would say the same for Stripe, but at least they'll help you migrate off their platform. Auth providers cant help you because the passwords are hashed…

It's one thing to host your own/maintain your own auth database, but there is a definite benefit of using a tool like Okta SSO to link your authn to other services, if that's your business.
Post reply on HN