Really slow progress with auth0. Switch to own auth solution?
Hi all,
Did you ever regret implementing your own auth solution instead of using an auth as a service one? Did you get hacked or did a really heavy problem occur?
I think it's quite a hassle to use a service like auth0, because I struggle a lot with it. My use case is a little bit complex and it really frustrates me to work with auth0. The amount of documentation is absolutely overwhelming. Either I find the thing I look for after a long time searching, experimenting and reading or I don't find it at all and get really demotivated.
I really move slowly and it demotivates me to work on my project, which is already validated!
Recently I had a problem where I spent almost the whole day for a small functionality. I just don't see really the return on invest.
From the emotional perspective, I would have switched already. But from the logical one, I still kind of hang on to auth0. I always think that it's better maybe to use a service like auth0 because of the experts there.
I have the feeling, that with my knowledge, I'll be able to implement auth by myself a lot faster. What do you guys think?
I would highly recommend against trying to do it yourself. For two reasons as you mentioned, it's where the experts are at (although there are many auth providers, so I wouldn't necessarily stick with Auth0). The second reason is the pure feature investment and management is overwhelming. If you think making it is a challenge, try maintaining it. Are you handling MFA, secure session management, or compromised passwords? How about password reset flow, unverified emails and CORS cookie management? What if you throw in AuthZ access control, custom JWT claims, OAuth integration with 3rd parties, or each of your tenants need their own connection.
Here's just the article on AuthZ complexity let alone all of Auth.
This is standard with SaaS though, there are so many, and not everyone is going to be a perfect match. You picked Auth0, maybe that was perfect for someone else, but not for you. It's probably time to look at alternatives long before you look at doing it yourself.
One of the most important points of SaaS is the support, even with all the docs in the world you might just need someone to help out. Indie Hackers is great, although it might not be realtime enough, depending on the solution you pick you might get the support you need. But I'll share a secret, lot's of SaaS companies have terrible support, and if you are looking for that, I can recommend this slack community.
Disclaimer: My company delivers AuthZ as a service, however it's easy to confuse what is being talked about here (AuthN) and what we provide AuthZ. So I'm adding a disclaimer that we are an expert in related Auth-things and thus have a bias perspective. Curious about what's the difference?
I think you’re overselling the complexity. If OP is using a framework like Django, auth is included for free. There are libraries that handle a lot, like Devise for Rails or Passport for Node.js.
But honestly, even rolling your own isn’t that much work. There are good libraries out there that can handle the tricky bits for you, like session management or password hashing. Password resets and email confirms are fairly simple flows too. CORS doesn’t have to do with authentication specifically, but it’s like a package and one line of code.
It’s also not a huge maintenance burden. This is code you generally write once, early on, and don’t really touch much after that.
This isn’t to say that it’s easy to do, and if you feel overwhelmed or want to hand it off to Auth0 you should do that and focus on your app! But if you’re feeling overwhelmed by Auth0 documentation… well, don’t be fooled into thinking it’s that way because authentication is some Gordian knot! Writing your own secure auth is very doable, even if you’re not an “expert”.
Edit: just checked out your profile and one of your projects is an auth as a service app. You should probably disclose that if you’re giving a strong opinion like this.
I use a NextJS (React) SSR app as the frontend and a C# Web API as the backend.
There are a lot of boilerplates and good libraries. I just have kind of the fear of getting hacked. But if I use a strong key for encryption, follow the best practices, I shouldn't be in a big danger.
As long as you keep your database safe, your app should be safe. Hacking your app will still be a concern whether you use an identity-as-a-service offering or if you roll out your own.
I've added one, however it's important to clarify what we focus on is AuthZ and what this post is about is AuthN. We don't have a vested interest here, because no matter what solution OP ends up choosing integrating with our products are orthogonal to that decision.
You should add a disclaimer that you run an Auth as a service platform. Not necessarily refuting what you are saying but it is imp. to disclose since you have a vested interest here.
I've added one, however it's important to clarify what we focus on is AuthZ and what this post is about is AuthN. We don't have a vested interest here, because no matter what solution OP ends up choosing integrating with our products are orthogonal to that decision.
I agree with this 100%. If you are having a hard time implementing a third party auth provider, you are almost guaranteed to make a mistake in how you handle authentication if you do it yourself.
Data leaks are expensive and you owe it to your customers to secure their information correctly.
Data leaks are not really prevented by using a 3rd party authentication service. You'll have client related data stored in your own database anyway.
Well I already implemented one several times using JWT. It's actually not that hard.
Auth0 has so much complexity in it, that I don't find the things I actually need. Like adding some more fields to the signup and saving them: This only works in user_metadata and the user has read/write access, which I don't want.
Well in that case, I stand corrected :). JWT auth makes sense, I will admit I’ve not used Auth0 but I have used AWS Cognito and I thought it was easier than building authentication around JWT.
Glad you got it figured out.
There's way more issures there than I was expecting. I went with open source stack originally because our architect told us to use, but I still have so many doubts about managing the technology. You did not say scaling, multi-region, disaster recovery, or auditing compliance. Why not?
I literally had the same issue with Auth0. It took wayy too much time to get started.
In the end, I went with good 'ol passportjs for auth.
I used Auth0 for awhile as well but then eventually gave up on it and built my own for much of the same reason as you. It was very difficult to get it to do the things I needed.
However, I would only recommend building your own if you have a strong understanding of security and related topics. You need to know how to implement MFA, password reset flows, proper password storage (hashing), OAuth (if you need it), etc.
I tried to build as much as possible with reputable, well maintained libraries. Don't even think about building OAuth on your own...
Use JWTs and do this yourself. Auth should and can be easy (and free)
I tried Auth0, Netlify identity, and Firebase. Ended up with Firebase.
Auth0 is highly overcomplicated for a standard dev project. It's more suitable for large enterprises, especially if you want to do anything that's not part of their "standard path".
I haven't tried this, but if you're anti-Google you could consider this Firebase alternative:
https://supabase.io/docs/guides/auth
+1 for firebase auth, highly recommended.
I understand your frustration. I was tempted to go with Django's built-in auth system for that reason. But ultimately chose Cognito. It was nightmare to integrate even with the great python-social-auth. The default integration didn't provide enough features, so I had to roll my own using the base OIDC provider. Ultimately, I'm glad I did.
Cognito provides so many features out of the box (even though it's missing quite a few) -- such as audit, leaked password detection, risk-based 2FA requirement, relatively easy Captcha integration, ability to act as an OAuth provider -- that it was well worth it.
If a breach in your app is not catastrophic, or you don't anticipate requiring advanced features, may be your framework auth system is fine. If your requirements are greater, you'll find using a hosted solution well worth it.
I've never regretted rolling my own.
I've had a similar experience with Auth0. I don't think there's anything wrong with implementing your own and it's a topic covered in the "main" intro book for Rails, Phoenix and nearly every single full-featured back-end framework I've used. Laravel even has a built-in solution which works for most needs.
The two rules I try to keep by are:
Also, keep in mind that using a 3rd party service or library doesn't guarantee a lack of security issue! I highly recommend reading this piece by Jose Valim, who created the very popular Devise gem that became the go-to auth library for Rails devs.
I've had a similar experience with Okta where I was spending waaaay too much time sifting through documentation and other issues. I still couldn't justify implementing a completely self-hosted Passport style solution as it still adds more complexity than needed. All my problems were solved when I moved to AWS Cognito and AWS Amplify. It was easier for me to wrap my head around their frameworks as well as finding it easier to work through their documentation. If I have a problem now I can usually solve it quickly. I suspect the same is true (maybe even more so) for Google's Firebase. Personally, I'd suggest giving either of them a try. Just my 2 cents...
What is your product and what backend language/framework are you building it in ? Auth is a solved problem already with frameworks like Django/Laravel/Rails/Node etc so unless you provide more details, I would say it is absolutely not necessary these days to roll your own or go with a hosted solution.
So don't necessarily implement it from scratch but look at a good library/framework that does it already.
If you use Next.js this might be interesting for you:
https://nhost.io/blog/simple-authentication-with-next.js
Maybe try out firebase authentication
Why not write a wrapper over OAuth to do that specific thing which OAuth does not do ... if that is a possibility. Down the line you can also think of switching to a different provider since you just need to rewire your customization part.
I'm actually building my own auth system right now for my side-project, using IdentityServer4 and .NET core.
If the rationale for building your own auth is because you think auth0 is painful, all I will say is do NOT do it. If you haven't done it before, I guarantee you it is 100x more work and complexity building your own service than relying on an existing provider.
The only reason I'm doing it is because I'm somewhat familiar with IdentityServer having worked with it for a year at my startup, and I see this as a long-term learning opportunity. Additionally I want to have full control of all services my app uses.
However, I'm already tearing my hair out trying to get the basics working (not helped by the fact I'm using an unconventional setup with Neo4j as the database).
*Although if you are using a similar tech stack to me, it'd be nice to collaborate
This comment was deleted 5 years ago.
This comment was deleted 4 years ago.