Auth as a service or not Auth as a service?
Hello fellow Indiehackers,
This is a genuine question I had a lot of times with myself and never seem to reach a conclusion so I thought to ask you guys.
Since we are all trying to be smart and minimize time and effort for launching our products, one important aspect is the user authentication, build or buy?
In my experience using services such as Auth0 is great as a time saver in the early stages of product development and thus accelerates launch, however down the road you may regret the lost flexibility and also the question is if it is better (or worse) to create your own signing/login experience instead of having a pre-made one.
And the locking effect is also something to consider, not completely trivial to migrate to a custom solution.
So what are your experiences?
Having our own Auth product on the market (although it does things quite differently than Auth0, for example making it easy to onboard offboard customers that are concerned about vendor lock in), there are a couple of points that teams usually get incorrect:
So it isn't just speed today, it's speed and security, and that continues forward.
Slightly off topic but I'm wondering your opinion on something. Most auth providers like Auth0, Firebase, etc. keep the user records in their own database and don't typically make the user record very customizable. How should I handle storing your own user data such as account settings, subscription level, roles, etc. Should I just wait until signup/login is complete and create my own database record with all this data separate from the auth user record?
My default answer is yes, although there are some things that help to be stored in the provider, generally speaking that data should something that never changes. If you store domain specific data, then the user might need to log out/log in to get the changes. You also still want to be in control of:
I see domain models today as more of the integration between services, you don't need to build N components, you need to integrate N providers to deliver value. Additionally, AuthN systems (and AuthZ) systems are coupled to identity, not to your implementation. If there identity changes, then the AuthN system should respond in kind, if their preferences change, then it's your model that needs to change.
When you need to change those things, having DB access to perform the migration is usually easier than making migrations against a SaaS service. When choosing a Saas provider, think what problem do I want to have solved. Most SaaS providers shouldn't be treated as DBaaS unless that is what they are providing (take Elastic Search or MongoDB for instance).
Here's a more concrete problem, let's say you want to have "groups" in your model (first off most AuthN don't provide groups), these "groups" should be able to see "user data" of other users. You can't import your access model into that SaaS so that your users could use that platform as is, you'll likely need group management (depending on the Saas) and then restrict which data is actually available. AuthN systems are very user-first, but you need group-first support. Profile pic, email, etc... will all be part of your AuthN integration, but email should be hidden from other users, since you don't want to expose that.
Storing a userId => { data }, is something easy and can grow over time, and might not need the sort of reliability that providers offer, but ease of access is critical. Providers offer higher reliability in exchange for access. In some cases you need GBs per user, indexed in specific ways, it might be tempting to use a provider to store that, but usually doesn't work out in the end. Every mistake we made with our AuthN provider (before we started providing our own AuthN product) was made because we stored data there.
Thanks for your reply. All these are valid points, still I have had some rough experiences like these:
I'm not sure why using Auth0 is any different from writing the solution yourself. Our service is completely opaque to almost any situation. (If it meant switching to our provider, let me know what the problem with the Auth0 component was in Heroku, I'm sure it wouldn't be actually difficult to make sure we have that use case solved)
If your Auth is down for 7 hours, then you do have a problem. But that's why your SaaS provider you depend on need to 5 nines (99.999% uptime SLA). Even 1 hour is unacceptable. For context our solutions run multi-AZ in multi-region. That's at least 6 datacenters that have to entirely be offline at the same time. So there is a higher likelihood you will be offline just based on cloud provider (not even development review process bugs) than we would be.
Hi Manuel,
I don't have any experience with implementing Auth as a service, but I would definitely give it a try on new projects. I've typically based authentication on the defaults provided by the framework I'm using - and that has always lead to headaches later down the line.
Authentication is something that is easy to do badly IMO, especially with increasing requirements (OAuth, SPAs, magic links, 2FA, id federation, reset / recover mechanisms etc), the complexity is probably better to left to the experts if security and flexibility is high up on your list of priorities.
Yes, I agree, that is like the biggest pro argument for using authentication services.
Hey Manuel, great question. I work for Auth0 in my day job in developer relations, so just want to chime in with a few product-specific bits of info in addition to the great answers here. FYI, Auth0 is extremely customizable and extensible to help you scale. You can customize your login screen and also customize and extend the login flow using a feature like Actions. Auth0 scales really well ; we have customers ranging from startups (check out our startup program) to enterprises. Hope that helps -- we also have a very active community forum if you need help implementing any of this. Cheers!
I especially like the idea of using Auth as a service if you're building a B2B application. Eventually you're going to get into companies that have more complex authentication needs like SAML, which might be difficult to build yourself but requires checking a few boxes in an authentication service.
I personally have always used third parties for authentication since I think rolling out your own authentication service is too much work and too risky since security issues will be left in your hands to deal with. Social sign-in through Google/Facebook/Apple/Twitter/... is an exception to that rule since you are only collecting emails/profile-pics/first-and-last-names and no passwords via the API.
*I get why some of you guys will disagree with me for obvious reasons
I'm not sure why, but I find it really interesting that this (auth) seems like extra work in 2021. Since I work with Rails (API backend), it's trivial to add Devise or Doorkeeper and I can have auth working in just a few minutes. Having worked with Django in the past too, it's just as trivial over there.
So I guess it depends on what you're coding it in, maybe?
Yeah as a Node developer I've heard stories about how simple it is to hook up things like this in other stacks, like I think Laravel has it built in by default? Node is much less opinionated so you get a lot of options but (imo) they're mostly a pain to work with.
Yes, in Node we had PassportJS but it is largely unmaintained since several years back, still works for many cases though: http://www.passportjs.org/
It is still not a five minutes job, you need to implement a lot of stuff until you have something production ready.
Yeah I've used Passport for most of my past projects, it's not too bad especially since you can find a lot of tutorials online, but I'm trying to move more to third party auth providers as well just to remove all of that burden.
Agreed that there's a gap here for a lot of JS devs. Next Auth seems to be a great choice that balances flexibility and speed. In the end, I'd probably still lean towards a paid service though.
I agree with you, but why do you say that?
(I also like the idea of using next auth, but seems a better idea to use a third party service)
Typical build vs buy pros and cons. Buying I think is less expensive when factoring in my time and any future headaches with auth and the quality will likely be better and in regards to security, that's pretty important to me.
This comment was deleted 4 years ago.
I generally recommend using a boilerplate that has authenticated included. That way, you eliminate the time needed to build one, and it's faster than integrating a third-party service. You then have the benefit that you can modify it however you want should you need to.
Switching from a service to a custom solution down the line is going to be a massive headache when you have users, so best to build in the scope for flexibility right from the beginning.
Definitely like the idea of using Auth0. But if you've built something before I'd say it's simpler to just copy-paste the previously created login. If you have nothing I'd say even having a pre-generated template which gives you boilerplates for signup/login code is good. Whatever would let you get past the boilerplate features and onto the main sections of code.
My opinion - If you've ever done it before just do the same again, if the last time you rolled your own do that again. If you've used auth0 before or firebase use the same thing again. There's enough complexity with 2FA etc.. that you may have to change later, but wait till you know what you really need, don't second guess it.
Maybe even just hardcode it into your backend for the first few customers if you are doing a closed beta.
Currently building an app and had the same dilemma. Ultimately, i went for a simple (self implemented) authentication service with JWT tokens.
Reasons:
IMO you have to have a good reason to use such services like you want to outsource SSO or security is really (really) important.
I rolled my own auth to start with until I spun that out into its own service. It took me quite a lot of trouble and research to build it out completely though.
It's difficult to get it to a point that users expect it to be at. Email verification, resetting passwords, storing everything securely, and the like. If you want to learn about auth, then you should roll your own. If you couldn't care less and just want to create a product, then look into a provider. There are pros and cons to both for sure. If you're curious about what goes into building it out, I would be more than happy to talk with you more!