29 ms·
Three things to never build yourself: auth, notifications, payments
- micahzayner 5y agoAll 3 carry great examples of APIs managing the many APIs within.
- bdamm 5y agoWhat great examples do you know?
- swiley 5y agoLetting other people handle Auth and Notifications is a great way to get the rug pulled out from under you.
- blacktriangle 5y agoExactly, how are all the Auth0 customers feeling about that acquisition?
- worldsoup 5y agounclear if we will all have to switch off Auth0 with the acquisition but I've built a company with Auth0 as the auth provider and definitely would not take it back, saved us so much time and allowed us to focus more time on product market fit
- micahzayner 5y agoIn the end this is the whole goal of something like stripe, or even something like Courier. Let your engineers spend more time on PMF and building cool new features.
- joshmanders 5y agoOn the flip side the absolute mess of a headache my day job had during their recent what 3+ hour downtime, stopping our paying customers from accessing our perfectly working application that they pay for, because early days devs decided to use Auth0 instead of a battle tested rails auth lib has made us prioritize refactoring auth0 out of our system.
- PragmaticPulp 5y agoFeeling 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.
- switch007 5y agoNervous as we’re on an /extremely/ cheap (almost free) legacy plan.
- spoonjim 5y agoWhy can't you switch vendors?
- infamouscow 5y agoOne aspect that's difficult to navigate is migrating the passwords and MFA secrets.
- mooreds 5y agoDon't know why you are getting downvoted. Asking a vendor how you can get this sensitive data out before you commit to them is a great idea.
- davewritescode 5y agoThat'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 time as long as they supported importing hashes.
- PeterisP 5y agoThere's a big gap between "never build yourself" and "letting other people handle it". Yes, you should have full control over your auth, run it yourself and keep the data - but you still should not build it yourself, you should use well-established solutions/libraries built by others instead of trying to figure out e.g. what's the proper way to salt passwords.
- willeh 5y agoRegarding 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 you do have to pay for it, expiry gets tricky, the client code gets trickier, permissions get trickier. For most people it just isn't worth it
- mcescalante 5y agoWe are going through this currently. Have a large new system going in which relies on OAuth and JWTs and our IAM team is now spending a lot of time & energy with the developers on all of the use/edge cases with tokens, expiry, security, and whether the code should be in the client or the server. In the end it'll work out, but I completely agree that grabbing the most popular auth framework for your language will save a lot of headaches in the vast majority of cases.
- sjaak 5y agoTo make things easy I usually use "alg":"none". It makes using jwts a breeze. https://datatracker.ietf.org/doc/html/rfc7518#section-3.6 https://datatracker.ietf.org/doc/html/rfc7518#section-3.6
- jaywalk 5y agoI hope this is a joke.
- sjaak 5y agoIt was, but judging by the downvotes my delivery was off :)
- mooreds 5y agoLike 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! :)
- distortedsignal 5y agoThis article is from a business perspective. I sometimes write auth/SAML solutions. They're not super complicated once you understand the basics of the system.
- valachio 5y agoThis is a biased article
- valachio 5y agoThis is a biased article. I would not let another company handle authentication or notifications for my apps. Payments, yes.
- troygoode 5y agoSure, it is obviously biased – I started Courier because I think developers shouldn't be building their notifications infra themselves. Why would you offload payments instead of e.g. connecting directly to payment gateways yourself, but wouldn't do the same for auth & notifications?
- croes 5y agoPayment has lots of legal pitfalls if done wrong not to mention the financial damage.
- troygoode 5y agoFWIW given GDPR, CCPA, et al so do auth & communication. I'd honestly have a big problem with our team wanting to store passwords ourselves...
- croes 5y agoYou don't store passwords. And regarding GDPR, I have problems giving sensible data to third parties. Another point of failure and no control for me what happens to the data.
- worldsoup 5y agoBoth auth and notifications get extraordinary complex at even minimal scale. Obviously each business needs to decide which areas make sense to invest from tech perspective but LinkedIn and AirBnB each spend around $20m/year just on their notification systems. https://medium.com/airbnb-engineering/airbnbs-promotions-and-communications-platform-6266f1ffe2bd https://medium.com/airbnb-engineering/airbnbs-promotions-and... https://engineering.linkedin.com/blog/2018/03/air-traffic-controller--member-first-notifications-at-linkedin https://engineering.linkedin.com/blog/2018/03/air-traffic-co...
- unixhero 5y agoAnd crypto!
- jchw 5y agoCrap, 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 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.
- Raed667 5y agoI'm curious how people handled payments before Stripe? Did you integrate with banks directly? How different is that in terms of what Stripe offers?
- mocheeze 5y agoThere were, and still are, many gateway providers with APIs for payments. Authorize.net, NMI, USAePay, BrainTree, Payeezy, even Paypal was common enough once upon a time. And those are just a handful that I can list off the top of my head. (I know that some of those I listed have acquired each other recently as well.)
- jchw 5y agoI guess it depends on what counts as handling payments yourself. Stripe can handle just about everything to managing subscriptions and emailing invoices and more. At least nowadays. It’s a lot more advanced than systems that roughly just provide an API to manage payment methods and charge them, like Authorize.net for example. Also, handling the abstraction between multiple kinds of payment methods (cryptos, different card networks, PayPal, etc.) may also be a considerable amount of complexity that a payment vendor can help with. I have never directly interacted with the financial system at its lowest levels. I’ve heard it is quite a trip.
- mooreds 5y agoWe 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.
- Ensorceled 5y agoThis article should have been titled "getting started with Courier notifications" or something similar, it's a tutorial with a bit of "don't roll your own" advice at the beginning.
- capableweb 5y agoMore 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.
- wisemanwillhear 5y agoI'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 https://martinfowler.com/bliki/PackageCustomization.html
- micahzayner 5y agoThis is a great read.
- oblio 5y agohttps://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/ https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-... Predating Fowler by about 10 years.
- gentleman11 5y agoThere’s nothing I dread more than customizing software, and then having the supplier release a critical update that requires you to re-do the work and search for bugs. It’s so expensive and error prone, it really is just better sometimes to treat your version as a hard fork or else make your own system
- jchw 5y agoSure, 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.
- croes 5y agoSo this post is just advertisement for Courier's own service?
- rgbrenner 5y agoNever 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... You need the same algo or you cant authenticate using the data they have. 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. Pick an auth provider and you better believe in their business as much as your own. You will incur damage when you leave.
- ocdtrekkie 5y agoIt 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.
- AlchemistCamp 5y agoIn Elixir-land we're lucky. Jose Valim took his experience from writing Devise (the dominant Ruby gem for auth) and made auth generators for Phoenix apps! You own the user table, but the auth logic is written by an expert.
- void_mint 5y ago> 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.
- troygoode 5y ago100%. I'm old enough that when I started my career we were still storing credit card numbers on our servers (and many companies were unfortunately doing so in the raw...). PCI compliance luckily knocked some sense into the industry. Crazy to me that some people don't realize that PII and secrets like passwords are basically in the same category now.
- encoderer 5y agoI’m biased but I would add: monitoring
- mooreds 5y agoYes! 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.
- Havoc 5y agoMissing the obvious - rolling your own crypto
- remram 5y agoYou probably don't need any crypto code at all if you don't roll out your own auth or payment.
- xwdv 5y agoWhat’s wrong with basic auth over https...
- bob1029 5y agoI 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 "more complex" 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). 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.
- mooreds 5y ago> 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.
- jpm_sd 5y agoI'm a hardware designer, apologies if this is a dumb question about "auth". If you're creating a product that is primarily or exclusively for mobile devices, what's the downside of relying on "log in with Google" and/or "sign in with Apple"?
- sam_lowry_ 5y agoSome people would not login then, and a vocal minority will complain loudly.
- edmundsauto 5y agoFor your business, this may be a positive overall.
- deleted 5y ago[deleted]
- Anonashtonian 5y agoNo. Auth is not that hard, it's not hard to scale. It's the bloodline of every interaction between you and your customers. Nearly every "web" language has a open source Auth solution with modern jwts or jwts on cookies. Bcrypt and salting solves "storing passwords". Further more once you do it it's highly repeatable across products.
- sethammons 5y agoexactly. Don't be clever and try to do things like re-invent bcrypt or hmac or do things through obscurity. Use the libs. I've written many auth systems, it is not rocket surgery. It is one of those things where you need to do some reading and understand what is going on, but I'd argue you should do that for just about everything you are working on.
- intrasight 5y agoShould be titled "Three things you can't build yourself" as Apple mandates that you us theirs.
- cosmotic 5y agoThis list should start with Encryption and have a long break before it continues.
- m0llusk 5y agoNever is a really big qualifier. It is possible for practiced coders to build secure systems. This is how we get trusted systems. Trusting auth systems is always a gamble. Remember when Google 2FA was only actually checking the first factor? I sure do. 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.
- elric 5y agoIn 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). I'm glad Stripe mostly killed all that.
- TheRealNGenius 5y agoChallenge accepted
- kordlessagain 5y agoDon’t tell me what to do.
- bokohut 5y agoAs 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 "owning all the code" and "data control" 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 "cheap" 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's current temperature on so many fronts. Always remember that which you read is just someone else'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.
- wepple 5y ago> As a serial entrePAYneur I don’t follow > core foundational member of multiple payments companies If you’re building a payments company, your product is literally doing the payments yourself! > with each better than the last, So, the first ones weren’t very good huh? Perhaps you could have outsourced them? > Security will become paramount to everything and outsourcing for "cheap" will have a much greater cost than one realizes in the moment. You’re conflating the use of a 3rd party for cost reduction with using a 3rd party due to efficacy and efficiency due to specialization. There’s zero chance you’re as good at Auth as a whole team of security engineers at an auth provider, period.
- ethanpil 5y agoMethinks "Three things I can carefully build myself and gain a competitive advantage over everyone else who thinks they can't..."
- dhbradshaw 5y agoIt's been said a few times here, but it's important so I'm calling it out on the top level: Don't roll your own auth. But do feel free to use a battle tested auth library / or framework hosted in your own app. Then you get both benefits: 1. You don't have to put your destiny in someone else's hands, and 2. You're not getting the risks associated with building your own auth.
- NicoJuicy 5y agoA lot of people are talking about auth/jwt. I'm wondering for those who build it: - how did you implement impersonation - how did you implement tenants ( and switching in between). Most have a follow-up dialog after logging in, which you can select. - did you implement something in your gateway that checks the token, instead of every service separately ( too lighten the load to the STS)
- bourgwaletariat 5y agoI'm really surprised a Notifications as a Service company would suggest you shouldn't build notifications yourself. Shawking.
- cblconfederate 5y agoI 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.
- judge2020 5y agoConnecting things to the correct parts of other things can be just as messy and difficult as writing code :)
- brailsafe 5y agoAs a frontend developer, I'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'd approach deeply understanding it enough to do it right (regardless of whether it'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'm talking sane abstractions that you'd see Fowler talking about, and something that I could actually follow while writing code to do it.
- TeaB 5y agoAd
- scsilver 5y agoNot 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'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.
- oblio 5y agoDo you have any examples of blockchain based account management?
- kdeldycke 5y agoI did all three with a team of 12 engineers. But this was in the context of a cloud/infrastructure provider, for which IAM, billing and payments are the 3 pillars of the ecosystem. You just can't outsource these business foundations to a third party.