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

Never outsource Auth. Maintain control over user accounts. That&#x27;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.<p>I would say the same for Stripe, but at least they&#x27;ll help you migrate off their platform. Auth providers cant help you because the passwords are hashed... You need the same algo or you cant authenticate using the data they have.<p>And the only way off without a mass password reset is a silent migration in the background: migrate the user when they login.. but we all know that will take months and you will never get 100% to login during the migration period.<p>Pick an auth provider and you better believe in their business as much as your own. You will incur damage when you leave.

I agree with Payments (PCI-DSS hell) &amp; Notifications (especially email &amp; 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&#x27;s auth into someone else&#x27;s idea of a good time. Consuming external authentication providers like Active Directory is something we do today, but it barely registers as &quot;more complex&quot; than integrated user management because its still the same server+process handling everything and all of the authentication state still lives on the same box (AD writes audit logs but these are out of scope from the actual auth flow).<p>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 &quot;easier&quot; 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).<p>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.<p>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.<p>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 are plentiful. Maybe building it yourself no longer makes sense, but I do think owning your user database is a good idea, even if you do primarily lean on OAuth.

It&#x27;s been said a few times here, but it&#x27;s important so I&#x27;m calling it out on the top level:<p>Don&#x27;t roll your own auth. But do feel free to use a battle tested auth library &#x2F; or framework hosted in your own app.<p>Then you get both benefits: 1. You don&#x27;t have to put your destiny in someone else&#x27;s hands, and 2. You&#x27;re not getting the risks associated with building your own auth.

Regarding auth, I absolutely bought to JWT cool-aid but honestly if you&#x27;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 you do have to pay for it, expiry gets tricky, the client code gets trickier, permissions get trickier. For most people it just isn&#x27;t worth it

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.

No. Auth is not that hard, it&#x27;s not hard to scale. It&#x27;s the bloodline of every interaction between you and your customers. Nearly every &quot;web&quot; language has a open source Auth solution with modern jwts or jwts on cookies. Bcrypt and salting solves &quot;storing passwords&quot;. Further more once you do it it&#x27;s highly repeatable across products.

This article should have been titled &quot;getting started with Courier notifications&quot; or something similar, it&#x27;s a tutorial with a bit of &quot;don&#x27;t roll your own&quot; advice at the beginning.

So this post is just advertisement for Courier&#x27;s own service?

As a frontend developer, I&#x27;ve been wanting to expand my skills as a server-side developer, and have been a little lost on where to get started in building an auth system, and how I&#x27;d approach deeply understanding it enough to do it right (regardless of whether it&#x27;s the right business choice or not, it seems likely worthwhile to be able to do it). Does anyone have any good resource that would provide a robust exploration into building this kind of system, either in a specific language or just a general one? I&#x27;m talking sane abstractions that you&#x27;d see Fowler talking about, and something that I could actually follow while writing code to do it.

In the early 2000s, a significant part of my income came from payment integrations. Everybody and their grandmother was jumping on ecommerce, and payment processors made it a bloody pain. To this day, I will never understand why, but it seems like they deliberately made it hard. And expensive. One of the companies I worked for had contracts with dozens of different payment processors, a lot of thought went into how to direct payments to the cheapest processor for whatever type of transaction (country, amount, card types, risk of chargebacks etc).<p>I&#x27;m glad Stripe mostly killed all that.

Methinks &quot;Three things I can <i>carefully</i> build myself and gain a competitive advantage over everyone else who thinks they can&#x27;t...&quot;

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

Never is a really big qualifier. It is possible for practiced coders to build secure systems. This is how we get trusted systems.<p>Trusting auth systems is always a gamble. Remember when Google 2FA was only actually checking the first factor? I sure do.<p>In my business the simple account and password ID model is insufficient. Most of our accounts are for families or organizations with complex contact protocols. Because on site service is the product we have the luxury of extensive physical in person verification. Assuming that every auth issue is for a typical Internet SaaS is a huge mistake.

I&#x27;m really surprised a Notifications as a Service company would suggest you shouldn&#x27;t build notifications yourself. Shawking.

I&#x27;m a hardware designer, apologies if this is a dumb question about &quot;auth&quot;.<p>If you&#x27;re creating a product that is primarily or exclusively for mobile devices, what&#x27;s the downside of relying on &quot;log in with Google&quot; and&#x2F;or &quot;sign in with Apple&quot;?

I often wonder why startup devs earn such high salaries if apparently they outsource everything, and are very opinionated about it, and have the quotes from business gurus to support those opinions.

This article is from a business perspective.<p>I sometimes write auth&#x2F;SAML solutions. They&#x27;re not super complicated once you understand the basics of the system.

Not to be jumping on bandwagons but it seems to me like decentralized block chain based accounts abstract both payments and auth out of your app and into a unified audited protocol. And since its a ledger, couldn&#x27;t you include notification information aswell? I feel like this is the killer feature of all these dapps, 2 of these features come built in.

A lot of people are talking about auth&#x2F;jwt.<p>I&#x27;m wondering for those who build it:<p>- how did you implement impersonation<p>- how did you implement tenants ( and switching in between). Most have a follow-up dialog after logging in, which you can select.<p>- did you implement something in your gateway that checks the token, instead of every service separately ( too lighten the load to the STS)

Missing the obvious - rolling your own crypto

As a serial entrePAYneur and the core foundational member of multiple payments companies responsible for all hardware and software architected, assembled and constructed with my very own hands I would sternly disagree with this article. I have done exactly what this article states not to do and have done so multiple times with each better than the last, it only takes an interest and an insatiable desire to learn. The world will come to learn the importance of &quot;owning all the code&quot; and &quot;data control&quot; as the cyber issues continue to cost countless billions and in time more and more bodies. Security will become paramount to everything and outsourcing for &quot;cheap&quot; will have a much greater cost than one realizes in the moment. Those that take greater risks have much greater reward and those risks shape the future for where we are today. My current efforts are the really fun stuff given the world&#x27;s current temperature on so many fronts.<p>Always remember that which you read is just someone else&#x27;s flavor of an experience in which they try to convey their ways on you. I am not bashing what they wrote just recognize how things would be if risks are not taken.

I’m biased but I would add: monitoring

I did all three with a team of 12 engineers.<p>But this was in the context of a cloud&#x2F;infrastructure provider, for which IAM, billing and payments are the 3 pillars of the ecosystem. You just can&#x27;t outsource these business foundations to a third party.

This list should start with Encryption and have a long break before it continues.

Should be titled &quot;Three things you can&#x27;t build yourself&quot; as Apple mandates that you us theirs.

And crypto!

All 3 carry great examples of APIs managing the many APIs within.

Challenge accepted

What’s wrong with basic auth over https...

Don’t tell me what to do.

Ad

Letting other people handle Auth and Notifications is a great way to get the rug pulled out from under you.