51–60 of 193 posts
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.
Except when there are none, you have to build it yourself.
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.
> If it’s a core business function — do it yourself, no matter what.
https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...
Of course, then the issue becomes "what is core?"
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.
Proper password and session management have been made accessible for many years if you use any "modern" backend.
Letting other people handle Auth and Notifications is a great way to get the rug pulled out from under you.
That's not true at all. Most vendors, if you make them specify it in a contract, will provide you with a way to export the hashes and some vendors support importing users with existing hashes. Okta in particular will import existing hashes. My company moved to Okta from a home grown solution in 6 months and I suspect after the work we put in place to facilitate that would allow us to move somewhere else in even less…
Does this mean that anyone who didn’t know to do this is screwed?
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.
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.
Good luck to you!
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.
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…
You don't have to use JWT to get a standalone solution (see for example this guide which I wrote: https://fusionauth.io/docs/v1/tech/guides/single-sign-on/ JWTs are used briefly, but most of the heavy lifting is done with application sessions).
If you have a single application, definitely use devise, passportjs, spring security or whatever is in your framework. 100% agree. But pretty quickly you often are adding in a forum, helpdesk, GSuite for employees, etc etc and having a single source of truth for a user is good.
We started trying to plug our app into an external SAML authentication flow (Azure) and it is making it much harder to prove certain semantics around user session lifetime and app security. Maybe it would be "easier" if we had just started with cloud native shiny BS, but I doubt it. Auth state would still be scattered across multiple systems, even if they all lived in Azure (or wherever).
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.
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 don't think deciding not to do something out of fear of doing it wrong is the right approach... If it's business decision then at least it's backed with some reasoning - don't do it because it's cheaper to buy it.