Letting other people handle Auth and Notifications is a great way to get the rug pulled out from under you.
Why can't you switch vendors?
One aspect that's difficult to navigate is migrating the passwords and MFA secrets.
Three things to never build yourself: auth, notifications, payments
31–40 of 193 posts
Re: Three things to never build yourself: auth, notifications, payments
#32Letting other people handle Auth and Notifications is a great way to get the rug pulled out from under you.
Exactly, how are all the Auth0 customers feeling about that acquisition?
Feeling fine.
As far as I can tell, nothing has actually changed from the customer perspective. It's not like Auth0 is going away or becoming unusable. Okta didn't spend $6.5B to burn all of Auth0's customers.
Re: Three things to never build yourself: auth, notifications, payments
#33I’m biased but I would add: monitoring
Re: Three things to never build yourself: auth, notifications, payments
#34More 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.
I've always thought this statement from Martin Fowler was right on target.
> Boiled down this means that if the business process you are supporting is part of your competitive advantage you should build custom software, if not you should buy a package and adjust your business process to fit the way the package works.
Source: https://martinfowler.com/bliki/PackageCustomization.html
Re: Three things to never build yourself: auth, notifications, payments
#35Never 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 is probably true that outsourcing your authentication to another party is probably bad, you probably should not write your own. So you should likely use a package for your auth code written by someone who focuses heavily on that.
Re: Three things to never build yourself: auth, notifications, payments
#36Crap, 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?
Re: Three things to never build yourself: auth, notifications, payments
#37More 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.
I've always thought this statement from Martin Fowler was right on target. > Boiled down this means that if the business process you are supporting is part of your competitive advantage you should build custom software, if not you should buy a package and adjust your business process to fit the way the package works. Source: https://martinfowler.com/bliki/PackageCustomization.html
This is a great read.
Re: Three things to never build yourself: auth, notifications, payments
#38More 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.
Sure, this is understandable wisdom. However, outsourcing has its risks too, as you need to trust who you are outsourcing to, often with your critical data, and your user’s data. Not only that, but you hard-depend on someone who does auth. Will these companies all be around in 5 years? Do they meet your security and compliance needs? etc.
I know why people are against building custom solutions. I’m just gonna say that I personally felt safer running third party Django apps that handled authentication but on a server I controlled, vs for example, Auth0. Not to mention the pricing model. The disadvantage is that you may have to put some effort into helping maintain it if it’s part of your critical path, but that seems like a good tradeoff to me. The point is to get an MVP out quickly, right? If things work out, having the resources to maintain an auth system seems reasonable.
This is not to pick on Auth0 so much; it seemed cool when I tried it out. It’s just scary to me to have my user database out of my control.
Re: Three things to never build yourself: auth, notifications, payments
#39Never 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.
Re: Three things to never build yourself: auth, notifications, payments
#40Regarding 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
I hope this is a joke.