3 ms·

This is literally the Auth0 first contact sales pitch designed precisely to scare you out of even trying to assess the risk of building it yourself. The realit

This is literally the Auth0 first contact sales pitch designed precisely to scare you out of even trying to assess the risk of building it yourself. The reality is, though, it's never been easier than it is today to build secure auth - yes, it's still hard to do it right - but less hard than it ever has been before. So many security features are now a checkbox on a cloud provider's web interface that would have been a manual implementation of the underlying protocol a decade ago. So many languages have matured battle-tested OS libraries for handling the especially sensitive parts like crypto. This notion that it is a "no-brainer" decision to happily trade your customer database and a % of revenue to remove the burden of stewardship seems crazy to me.

deergomoo 5y ago
Not to mention there’s a whole lot of middle ground between writing your own auth logic and using a hosted service. Any reasonably popular web-oriented language has plenty of fully featured, high quality libraries you can often just drop in. Hell, we use Laravel at work, which includes pretty robust auth features out of the box. It feels like such table stakes stuff for a web framework that I find the idea of paying for a third-party cloud service absolutely bananas. It also includes pretty solid notification and payment solutions too, though these usually plug into services like SNS and Stripe and don’t really fit the “self hosted” bill.
- beardbandit 5y ago
  I think that's where the confusion lies. Are people suggesting someone to write their own auth from the ground up, or write auth in coordination with their stack's auth library of choice?
  - joshmanders 5y ago
    It appears to me the assumption these people / articles make is that nobody is using existing hardened production ready libraries, but hand writing everything from the ground up for their todo app. Because otherwise their message falls flat on its face.
colinclerk 5y ago
> but less hard than it ever has been before I have a very vested interest in this (founder Clerk.dev) - but the exact opposite experience is what led us to start Clerk. Auth was easy when it was just email verification and choosing the right hashing algorithm. I used to pull Devise off the shelf and get it going in 30 minutes. But these days, the simple solution is far from complete. I grew most frustrated trying to setup the rest... - Single sign-on / Oauth with proper de-duping so users can always sign in regardless of how they signed up - 2fa so users can better secure their accounts - Integrations with a leaked password corpus (haveibeenpwned) to prevent credential stuffing attacks - Active device tracking and remote session revocation You can launch without these things, but it's definitely impacting your overall security and the conversion rates through your sign up and sign in flows.
- zzt123 5y ago
  I found these features quite simple to implement. What gave me a headache was advanced anomaly detection (both from the per-account and per-requester perspectives) and handling. For me, there is no bottom of the well on those things, and they are the killer features of auth as a service.
bob1029 5y ago
> So many languages have matured battle-tested OS libraries for handling the especially sensitive parts like crypto. We use CSPRNG/SHA256/SHA512/AES/3DES/RSA primitives in .NET without any trouble. Microsoft made it pretty difficult to fuck things up as long as you don't sprinkle Math.Random in with your session token logic like a jackass.

deergomoo 5y ago

Not to mention there’s a whole lot of middle ground between writing your own auth logic and using a hosted service. Any reasonably popular web-oriented language has plenty of fully featured, high quality libraries you can often just drop in. Hell, we use Laravel at work, which includes pretty robust auth features out of the box. It feels like such table stakes stuff for a web framework that I find the idea of paying for a third-party cloud service absolutely bananas. It also includes pretty solid notification and payment solutions too, though these usually plug into services like SNS and Stripe and don’t really fit the “self hosted” bill.

beardbandit 5y ago
I think that's where the confusion lies. Are people suggesting someone to write their own auth from the ground up, or write auth in coordination with their stack's auth library of choice?
- joshmanders 5y ago
  It appears to me the assumption these people / articles make is that nobody is using existing hardened production ready libraries, but hand writing everything from the ground up for their todo app. Because otherwise their message falls flat on its face.

colinclerk 5y ago

> but less hard than it ever has been before I have a very vested interest in this (founder Clerk.dev) - but the exact opposite experience is what led us to start Clerk. Auth was easy when it was just email verification and choosing the right hashing algorithm. I used to pull Devise off the shelf and get it going in 30 minutes. But these days, the simple solution is far from complete. I grew most frustrated trying to setup the rest... - Single sign-on / Oauth with proper de-duping so users can always sign in regardless of how they signed up - 2fa so users can better secure their accounts - Integrations with a leaked password corpus (haveibeenpwned) to prevent credential stuffing attacks - Active device tracking and remote session revocation You can launch without these things, but it's definitely impacting your overall security and the conversion rates through your sign up and sign in flows.

zzt123 5y ago
I found these features quite simple to implement. What gave me a headache was advanced anomaly detection (both from the per-account and per-requester perspectives) and handling. For me, there is no bottom of the well on those things, and they are the killer features of auth as a service.

bob1029 5y ago

> So many languages have matured battle-tested OS libraries for handling the especially sensitive parts like crypto. We use CSPRNG/SHA256/SHA512/AES/3DES/RSA primitives in .NET without any trouble. Microsoft made it pretty difficult to fuck things up as long as you don't sprinkle Math.Random in with your session token logic like a jackass.