I mean, it has the same benefit of other SaaS, you get to avoid building something and can spend that dev time on building something that solves a unique problem AND you have the benefit of knowing that you get to focus 100% on your app or site's problems and features, and that you have the entirety of Auth0 focusing on keeping your authentication working. I can promise Auth0 is better at building scalable, secure, and resilient authentication solutions than most dev teams, and I've been on a team that's built out a 1000s of logins/hour and 100k requests/hour enterprise grand IDAM solution.
If it's data security or something else that's your concern, you can host the data in your own database with their enterprise package.
General disclaimer: I'm a paying Auth0 customer but just use it for authentication, and it saved me a hundred hours of work for a pretty reasonable price.
I've never really worked with a language that didn't have myriad options for open source, configurable, plug and play authentication. I can't imagine spending 100 hours doing authentication.
I guess it depends on your use case; I do not really find it reasonably priced but then again, I need neither the scalability nor all the features it offers. Gotrue or supertokens are fine for what we do.
Auth is both simple and hard to get right. It's virtually the same everywhere. One group of people getting it right is better than every company trying to figure it out for themselves. It's exactly the right thing to farm out to a 3rd party.
Only on HN will you be told "you're an idiot if you outsource your auth" and "you're an idiot if you roll your own auth" by the same group of people.
Most people are using something like laravel or rails that has auth scaffolding built in for you, so both outsourcing and rolling your own are obscure dirt road paths that are rarely suggested.
There's a difference though between farming out to a SaaS product like Auth0 and rolling your own. You should absolutely not try and write your own Oauth2 server unless you really, really know what you're doing. But there are a lot of options for self-hosted auth services that are rock solid and battle tested.
Depends on what you mean by maintain. If you use one of the well-supported open source solutions like Keycloak then it is very actively maintained with regular releases, bug fixes, new features (U2F support etc). But of course you need to run your own infrastructure (database, application servers, load balancer, maybe separate infinispan cluster if you want to go wild). If you don't have the operational capacity to do that then maybe a SaaS solution is right for you.
It depends on your needs. What if you provide a SSO solution in your product, your customer is using Okta (or any other IdP) and that IdP goes down? There's nothing really you can do then unless you have other means of authentication.
To me the exact opposite - it’s seems like a prime candidate to be a third party service.
It’s something easy to get wrong, and has a long tail of work which is extremely generic (supporting all the different social logins, two factor authentication, password reset emails, email verification, sms phone number verification, rate limiting, etc...)
Really? Because of all the things I don’t want [myself or my colleagues] to write, a secure authentication management system that connects to multiple with providers is up there.
Really the only case where it makes sense to farm something like this out is to Google (if Google and the US military aren't in your threat model) because Google's G Suite login system (which can be used as an IdP) is, as far as I can tell, the exact same one they use for @google.com.
Incentives are perfectly aligned there, and if anyone can keep a system running and secure (to everyone except the US military which can compel them), it's them.
