Three things to never build yourself: auth, notifications, payments
1–10 of 193 posts
Re: Three things to never build yourself: auth, notifications, payments
#2All 3 carry great examples of APIs managing the many APIs within.
Re: Three things to never build yourself: auth, notifications, payments
#3Letting other people handle Auth and Notifications is a great way to get the rug pulled out from under you.
Re: Three things to never build yourself: auth, notifications, payments
#4All 3 carry great examples of APIs managing the many APIs within.
What great examples do you know?
Re: Three things to never build yourself: auth, notifications, payments
#5Regarding 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
Re: Three things to never build yourself: auth, notifications, payments
#6This 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.
Re: Three things to never build yourself: auth, notifications, payments
#7Letting 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?
Re: Three things to never build yourself: auth, notifications, payments
#8Letting 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?
Re: Three things to never build yourself: auth, notifications, payments
#9Regarding 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…
We 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.
Re: Three things to never build yourself: auth, notifications, payments
#10This is a biased article