Use Authentication as a Service, or build it myself?
Over the years I have built a number of software applications that required user authentication. So far I coded the auth functionalities myself (done this in Python, NodeJS and Go), however every time I came to the conclusion that it was still quite some work to do it right. Especially with also setting up required verification code emails, password reminder emails, and making sure all user data was always correctly available and secure (i.e. the database part) etc.
Since authentication is a vital component of most software, it has to be done right, but I want to save time an hassle in the future. So I looked into using an Authentication as a Service, instead of building and maintaining it myself. I found AuthaaS providers such as: Auth0, Clerk, KeyCloak, Amazon Incognito, a.o.
However they all seem so overpowered for the thing I’m trying to achieve, just plain and simple user authentication with an email and password. I don’t need Authorization, user roles, Multi-Factor Authentication, Single Sign-On, etc. Nor do I expect a huge number of total registered users.
💡 Does anyone of you outsource their user management by making use of Authentication as a Service? And if so, why that particular service? Or else, why did you decide to code it yourself?
I'm a big fan of supabase. Set up is quick and I can easily manage user data in the same platform since it provides auth/db together - I mean things like handling expiration dates if a user cancels their subscription, etc
Good to hear. I have been working with firebase, as I understand supabase is quite similar. With both setup seems more simplified than coding all yourself, still it is rather low-level imho.
On a side note, I read some posts online that their documentation is not clear and incomplete, but maybe they have fixed that by now.
Yeah I think they're pretty much identical feature-wise. The documentation can be tough at times, especially without knowing the fundamentals of server/client, etc.
I've actually been thinking of releasing a NextJS auth tutorial with videos and a boilerplate to help people understand it better.
Got it, that shouldn't be an issue here. Nevertheless I'd be very interested in checking out your tutorials once you have them!
I’ve thought about this a lot. I’ve been the CTO of venture backed startups and successful bootstrapped companies, I’ve worked at fortune 50 companies, and now manage dev teams for clients of all sizes. I strongly believe in buying over building for anything that is not core to my product.
But Auth messes with my head on this.
At a recent-ish startup (series B, sold in Jan), I made the decision to use Auth0. I could have used the open source Auth framework I built before that was used in production by a previous company, but I didn’t want to have to be the expert. Auth0 was JWT based, free for low numbers, had a bunch of UI that was plug and play, etc. I regret using them.
The first issue we ran into was “quotas”. Auth0 will rate limit you based on the number of requests they get. Even if those requests are rando bots trying dictionary attacks or breach files that have nothing to do with your service. Bots can eat up your quota, and now legitimate users are locked out. When we asked for help, they told us to turn on bot detection. After we did, they told us we needed to upgrade to the enterprise plan (~ $20k/yr). You can put your own captcha or whatever in front, but now you’re building and using a service.
The next Auth0 issue we ran into was we had a successful marketing campaign for a free / lead magnet service. This quickly put us over the free limit of users and we had to choose to rapidly replace Auth0 while under the gun or sign an enterprise contract with them. We went with the enterprise contract.
Even after this I was on team “buy not build”. So last month when I started building https://upfollow.app I decided to use Firebase. We used Firebase for a client build last year and it worked well. I had to rip it out.
Firebase supports magic links/sign in with email. I wanted magic links. Firebase does not let you customize the sign in emails. Like at all. This is what I was stuck with:
—-
Hello,
We received a request to sign in to upfollow-4491b using this email address, at 2024 March 05 19:17 Z. If you want to sign in with your [email protected] account, click this link:
Sign in to upfollow-4491b
If you did not request this link, you can safely ignore this email.
Thanks,
Your upfollow-4491b team
—-
I could not imagine what a prospective user would think about that.
I “gave up” and just used https://npm.im/authentic-server . I added magic links pretty quickly. It works fine.
I still don’t think I’d use something like Authentic for a client—I don’t want to be on the hook for support. I would at least try some other recs in this thread.
I’ve learned my lesson for my own projects though. I’ll use my own Auth library.
Thanks for sharing such an elaborate story @dguttman. Sounds like you have experienced the full scope of the matter.
I also have the impression that vendor lock-in, and therefore large dependency on their policies and (sudden) changes in pricing is a big risk. Which eventually could be more harmful to your company as a whole, compared to the costs of developing auth in-house.
It seems to be that passwordless authentication, like for example using magic links, is something that will become more ubiquitous in the future. Both for user and developer friendliness as lack of required support. Though there are still things to improve there
On the subject of magic links, you just reminded me! I ran into an issue when building magic links where they would be used/invalid before I ever clicked on them. Turns out that Gmail will automatically visit links in emails, and it was using up the tokens before they could be used!
I had to change Upfollow to have a “2-step” process where your click the link from the email and then after the page loads you click a button to actually use the token and log in.
@dguttman David, if the things are as you describe them and Gmail automatically clicks on the links, that means we can verify ANY Gmail address, EVEN if we don't own it, by simply registering and Gmail itself clicking on the verification link in the received email...
No, things definitely can't work like that.
I've now looked in my mail to see if the links in Gmail are direct or go through some redirect of their own, for example when you post a YouTube link in the comments section and EVERYTHING goes through their redirect - in the emails, the links point to the original location.
If you see fit and can spare the time, can you give more information on your claim to clicks, because it applies not only to verifying URLs but also to generating Magic Links and the fact that you've added a Second Step where the user Explicitly has to click.
I honestly haven't seen anything like this anywhere when I've logged into sites with Magic Links, and my questions are driven by the fact that if Gmail does click on All Links, it's extremely dangerous security-wise, and under certain circumstances, anyone can register an account with foreign addresses and gain access over them!
I don't know the specifics of when Google visits links (when you click the redirect, if its an unknown sender, etc...). I assume it has something to do with checking a link for safety. What I can tell you is that I was pulling my hair out trying to figure out why Upfollow wouldn't let me in via magic links.
The app was giving me a "token already used" error. This was impossible because it was the first time I was clicking on the link. After trying this a number of times I checked the logs for the server and some IP address from Kentucky was hitting the confirm address before I was. I looked up the IP and saw that it was Google. It might also have had Google in the user-agent, I don't remember. Now that I think of it, checking UA might have been another (probably more complicated) way to preserve the single-step flow.
Most services that I see that have you log in via email these days do it with a code not magic link (Slack). Others (Vercel) do it where you verify that two phrases match. I assume they are doing this to prevent any auto-visiting from causing security issues.
Unfortunately GCP no longer has logs from March 7th (when this happened), so I would have to do a separate deploy from the versions of the app right before the fix. Which I'm open to, but is a little bit more involved.
Many thanks for the comprehensive information.
This should be thoroughly researched as it pertains to any system that relies on registration/sign-in with Magic Links.
Manual code entry is extremely secure ( I noticed recently that Slask now uses Letters instead of Digits for the six-character PIN code, increasing the combinations from 1M to over 300M ) but it is a very bad User Expirience, especially on mobile devices and people have to read, remember and write, try to copy... it is bad in general.
What I have heard and can share is that transactional email services like Sendgrid for tracking purposes, also "click" on Certain links before redirecting.
For anyone implementing such functionality, these things need to be cleaned up and clarified, because it is Best Practice that requires the link be Time-Limited before it expires and to be used Only once, something we see in this case that cannot guarantee that it is the user that will click on it...
Once again, many thanks, these are very valuable observations, and let them remain here in the forum, for reference for others, people interested in the subject.
Great to see this detailed discussion emerging, I agree it is very informative for future readers/builders.
Interesting. Are you using your own coded magic link service?
I've been diving into them after some suggestions here. Never thought much of them t.b.h., but starting to get enthusiastic about magic links now
Yep, I added it to https://npm.im/authentic-server
I’m also of split mind about them. Many sites annoy me with them because I don’t want to switch to email and sometimes it will take its sweet time sending me the code. On the other hand, creating and storing a password the first time is also not great.
I'm a Firebase auth user and I don't use magic links but I may in the future, so I was curious about your issue. Here's what I found:
https://stackoverflow.com/questions/50075602/firebase-authentication-email-customisation
There is no way to edit any of the email templates that Firebase Authentication uses. The reason for this is that this allows bad actors to use Firebase to spam people, which would put the service at risk.
To control what message gets sent, you'll have to send it yourself and handle the verification flow with a custom email action handler. See How to modify Email Confirmation message - Firebase.
You could also take full control of the verification flow, and then use the Admin SDK to set the emailVerified flag of the user's profile.
Awesome, thanks for sharing! Proper documentation, or at least easily retrievable documentation also seems to be a persistent issue with many authentication service providers.
Got the impression they are often busy with building new features to serve a larger market, instead of excelling at the current solution they offer..
If it takes a lot of time to get up and running, the potential time savings by using a 3rd party service are also out of the window. Glad you managed to pull this up so quickly
Hi, we just prefaced some of the issues you ran into and actually build a pretty simple pure magic link based stateless auth flow. No excessive storage of any privacy related data. I mean the only actual persisted state is valid till. And that state comes from event sourcing. Means even if we purge the redis db the state is stored, we could easily recreate the state of any magic link issued. One core metric why we wanted just this one state and in redis is, to be super fast authorizing api request. It's basically a redis get we during a http options request. Never looked back.
Lucia Auth or Authjs (formerly next Auth) ftw!
I built our startup on top of nhost (supabase clone) after considering superbase.
DO NOT DO IT.
Nhost, superbase, pocketbase, firebase - all traps. They lock your startup in with easy-to-use demos and code snippets.
Everything is fine until you start to grow and change and iterate how your product works. All of a sudden you're stuck with "how pocketbase does it" and it's a pain in the butt.
My advise, if you're hacking a project together, these platforms can get you started quickly but don't be fooled - there is no longevity.
That's so true; I've been there, which is exactly why we host everything ourselves. As long as we're not yet at the scale of Netflix or similar, it's probably the best decision. We only pay for the energy for the main cluster (60+ containers running) and a smaller failover infrastructure in a different location. Hosting this ourselves saves us thousands a month, considering all the Redis database storage capacity we need. We can use any technology we want at virtually no extra cost. Last time someone asked about our costs for using Redis on AWS and similar platforms, my response was simple: Oops, sorry, we don't have extra costs.
Great advice, thanks for sharing @mmoli! I also think that these tools have a rather high dependency once you've decided to go with them and build you codebase around one of these tools.
Interesting to hear your first hand experience. What would you suggest to use after the so called 'getting started' phase?
The main 'unlock' for me was getting to grips with abstractions, dependency inversions and dependency injections.
These tools massively help push all the infra outside of your core domain and make it trivial to switch between db at any later stage.
I guess the starting point, is to make your own abstractions. We use Typescript so we have lots of:
Then you implement with whatever infra you're using at that time:
Happy to chat more if you're interested. Love this stuff and struggled A LOT with it.
I've used Firebase Auth for one of my own project even if I have more experience in backend systems.
I have couple of points.
Pros;
Cons;
Overall If someone is mostly interested & experienced on Frontend. I would probably suggest them to use one of the auth providers since it doesn't require any learning curve for server parts.
At the end, it mostly depends on what you wanna do with the application and it's flow.
Thank you @mehmetalisavas for lining this out. I fully agree. As with almost everything indeed: it depends...
To me it also seems that developers with strong backend experience are better suited to implement authentication themselves. Although still a lot can go wrong and outsourcing may be worth it. If one is less experienced or not experienced at all, it generally is better to outsource but remain aware of the downsides.
I personally have been a big fan of Supabase lately. Previously I used Firebase exclusively for all my mobile projects, as the documentation was lacking with supabase for a while. Now that supabase is a bit more mature, I have no issues with it and has become my go to, as I feel there is much less vendor lock in.
Thanks for sharing. It seems supabase is used by a lot of people here. I have experience with Firebase, so definitely worth trying the switch to Supabase too. Glad to hear it has also become more mature
I like to use third-party libraries, so it's "No, I let others code it for me", I guess. Devise (Rails) or django-allauth are awesome when building modern monoliths or MPAs. In my experience, authentication becomes much more complex when splitting the product into separate backend and frontend projects, which is a popular approach nowadays. In the past, I implemented authentication in Django and Node for a few SPAs myself, and it was not a fun experience. I imagine that integrating some Authentication as a Service may be a good idea in those scenarios.
Imo the best answer for most Indie Hacker's who are in the validation phase, especially for monoliths. Rolling it yourself is risky, but using a service costs money. Both introduce unnecessary complexity.
Importing a package into your likely small codebase that handles auth for you is just so helpful, I've used django-allauth and it works great.
PocketBase is a great modern Go based version of this, that's why I built https://deploysolo.com/ with it.
Agreed! However even with using a package you still need to setup and maintain the database and connections right to store the users data?
I will have a look into PocketBase, thanks for sharing.
If you're using an external service for a database like postgres or mysql, yes. But the framework handles the sensitive aspects like hashing passwords and actually executing the queries, which are all places indie developers could potentially make mistakes, we're all human.
If you're willing to use SQLite, it can be way easier, as its just a local file in your project directory. This is what I always do, because SQLite can handle 10,000+ users on even a $5/mo VPS, or more if scaled vertically.
If you need to scale a business to millions of users, then you can comfortably hire a team to migrate the architecture.
Spot on @mannders0n! How many companies will eventually have millions of users. If you reach that you will have the resources indeed.
I really like the SQLite suggestion, especially when starting out with something new.
Haha sharp, yes using a framework is essentially letting others do the coding for you. I fully agree with your, having that same experience for smaller or new applications.
Before you know you spend a lot of time building all kinds of authentication functionalities at the start of you project, when you like to focus on the actual value component..
I have built like 10 authentication systems by myself, and I strongly advise you to do it yourself, especially now in the early days when you don't have a product yet and you didn't validate it. For the MVP, or alpha version of your product, just use the free tier of an authentication provider (more than enough for every SaaS), and you can start from scratch with email+password, but also with social media auth, which will reduce some onboarding friction.
When I built these systems by myself, I always ended up spending like two months getting everything working, things such as:
And these take way more than you anticipate, because they include a lot of details.
For the MVP, try to code as less as possible, to just launch and start gathering feedback as early as possible.
Spot on @vladcalin! Thanks. It indeed takes a lot of time to get the details right, no matter the framework you are using.
Especially in the early stage of launching your product or service you don't want to spend to much valuable time on this.
I made an app called Client Note Tracker and used django rest framework on the backend. I used a couple packages to set up auth (dj-rest-auth, django-allauth) with regular email auth, social auth, and password reset. In the end it worked pretty well but took some extra time because the documentation was not clear at times.
Thanks for sharing, interesting to hear. I've also setup authentication with django, can't remember using those packages, but it was well over 5 years ago..
Worth looking into them. Nevertheless clear documentations seems to remain an issue with (many) open source projects. Hard to know the status in advance, for sure bad docs may take a unexpected large chunk of your time
As a SaaS maker that start a product initially with a home-made auth and then spent weeks to migrated to a dedicated auth solution, my suggestion:
Here's why.
First, auth is indeed one of the hardest part of making a SaaS if want a robust and smooth auth flow. The complexities:
Last but not least, the confusing account linking part, say that you provide email + password/OTP sign in and Google Sign In at the same time, then one user sign in with
[email protected]email via Google Sign In, then some day he sign in with email + password, and he got a whole new account, which is quite confusing. Ideally, a user should be linked to same account as long as he has the same email address, no matter he signed in with email, Google Sign In or any other social sign in providers.So overall yeah this is overly complicated if you want to smooth and robust auth flow for your SaaS project. I've experienced the whole decision making flow and did a big refactoring recently and I wrote down my experience in the following posts:
Hope this helps!
We actually build a pretty simple pure magic link based stateless auth flow. No bells and wistles, but it just fullfills what the user cares about:
Imagine the user get's locked out from Gmail. Now he can't access your product anymore even though he has payed.
The best:
And for our SaaS, we could integrate it smoothly with api key generation, payment provider, order fulfillment and product setup.
Two things need more clarifications.
First, the reason for my insist on integrating OAuth (social sign in) is Social sign-in can significantly increase conversion rate, with studies showing an average improvement of 20–40%. My case of PPResume has confirmed this.
Second, most of the auth providers on the market is commercial and Auth0 is the leading player for sure, however, auth0 has an insane pricing plan and it has risk for vendor lock in. But there do have some open source, dedicated auth solutions, where you can self hosted yourself if you has some SRE skills. I self hosted logto and it works quite well for me, saves me tons of time.
Thank you so much @xiaohanyu for sharing such an elaborate review. I think you analysis and issues you raise with service providers are spot on.
I will read the pages you included for further reading. It surely helps in the decision making process. If you know that you eventually will need a huge refactor and outsource the whole authentication to a 3rd party, why bother building it yourself in the first place, right?
That is absolutely correct!
One more thing is, migrating user data from one auth to another auth often means lost of password, as password are not store in plain text, and different auth vendors may use different password hash algorithms. In my case I lost all my users password when migrating home made auth to logto.
I built by hand a few times but it does not feel like moving the needle mvp wise. So this time, for www.gami5d.com, I used cognito. Just basic auth service and it was easy to integrate once you knew how
You are the first I hear having used Cognito, I was under the assumption that service only serves really big clients (1000s of MAU), but maybe you have. Good to read it's easy to integrate
:) not yet - but i hope to have 1000' s someday.
I just needed an auth service to setup quickly - it was a couple of hours work.
Code based 2FA is really easy to implement on the server. The client side is already done --- lots of mobile apps available for both iPhone and Android.
You just need to show the user a QR code on the screen in order to simplify the setup. There is lots of code available to do this. I do mostly web based apps so I use some Javascript for this.
Thanks. Wouldn't using a QR code actually complicate the setup? Or what is you experience with that? Afaik QR codes are not (yet) common in authentication processes, in contrast to payment processes for example
Definitely as a service! Although all big three has it's stand alone auth solutions, I also strongly recommend Supabase and Firebase.
Happy coding :)
Thanks!
I’ve done it once and I reuse code from my past projects and maintain same stack. Projects are always quite different but auth is always pretty much the same.
Makes sense, especially if you can wrap that code in some kind of micro-service you can invoke for any other project
I use supabase and it is great till now. Using custom auth has its own set of problem
I use next-auth and supabase for all my apps. Very quick and free to start.
Auth0 is too expensive.
AWS cognito is ok: you can check how I implement it: https://saasconstruct.com/blog/the-tech-stack-of-a-simple-saas-for-aws-cloud
I heard so too.. not sure if it is true, but I read (rumours) that many companies are moving away from Auth0 because of insane price jumps.
Thanks for sharing! And could you define 'ok'? Seems different from 'good', is it lacking someting?
Initial setup can be slightly tricky, but once you are done, it is good. And very cheap.
I had the same question regarding Auth0 and cognito and did not regret going with Cognito.
Check how I did it on my comment on Reddit: https://www.reddit.com/r/aws/comments/1c7mob7/comment/l09v8ai/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
Here is the blog post on my AWS architecture, including Cognito:
https://saasconstruct.com/blog/the-tech-stack-of-a-simple-saas-for-aws-cloud
We just build a self service authentication. Meaning the user generates cryptographic protected keys by himself on our page and gets associated magic links containg a proof for these keys.. With this link they can access product configuration, dashboards a.s.o.
That sounds like a really cool feature! I'd love to hear more about that
Some other cool feature is that it is basically stateless regarding authentication and auhtorization. What we do is store a valid till in redis for each key after payment. This way we can extend, reduce or cancel subscriptions easily. For example reducing in case the user requests a refund via the payment provider. Even the email is not stored but the user provides the email and a magic link is generated based on some other reference like product type, domain in our case or payment transaction key. It is a pretty simple flow but bullet proof and pretty resilient against any attack. Further no GDPR or whatsoever concerns. 😊
You really get me exited about this! Is there by any chance some reference documentation or code you can share on this?
I would love to give it a shot at implementing it for a project. The simplicity for both end-user and developer sounds neat.
Using Authentication as a Service simplifies user authentication by outsourcing it to specialized providers, ensuring security and scalability. Building it yourself requires expertise and resources but offers more customization and control.
Yes exactly, what is your favorite provider to outsource this, if any? Or do you code the authentication components yourself?
To me, the auth provider doesn't change much in terms of productivity as long as I'm using NextAuth. Amazing library, truly.
Interesting! Do I understand correctly that NextAuth is a library via which you can connect with any (or a number of) auth service providers? Looks promising
Exactly. It also works so smoothly with Next. If you're building with Next.js, I highly recommend it.
Cool. I'm not doing anything with Next.js atm, but who knows what the future holds.. Great suggestion anyway
For the last few years I’ve used open source solutions or third party services to deal with this problem and no longer reinvent the wheel.
I found that even though I want to start small in the beginning I always need to add more features, security or adjust to requirements from enterprises do it’s better to integrate a solution that can grow with my needs from the start.
I for one had great success with Keycloak as my Authentication handler and the great thing about it is that it’s free and open source.
I agree with this approach. Finding a reliable open source package that provides the base features needed will allow you to add anything you need later. I'm sure there must be something on GitHub that is usable for this situation.
Thanks! What is your experience with documentation and customer support for open source authentication packages?
That also seems like a thing where service providers (can) make a difference
Yes if you are not able to use, or modify, or support the open source package yourself then you should purchase from a service provider that will be able to do it for you.
Yes, that makes sense to not reinvent the wheel and also pick a provider that you can grow along with. I experimented with Keycloak a while ago, precisely because of its open source and free character, but found it a bit overwhelming back then.
Esp. the setting up the self hosting as I remember, had to do quite some things to get started, but things (and my skills) have improved since then.
Interesting to have a look into it again.
I definitely don't want to spend time on something like authentication; I'd rather focus on the features for my app instead. That's why I prefer to use backend solutions like Appwrite.
You said:
So what if they offer more features? Is it because it also costs more than you're willing to spend?
Thanks for your reply and suggestions, I will have a look into Appwrite!
Agreed that it is not a bad thing if they offer more features than you need, only when it comes with a higher price it is. However my experience is that solutions with many features also come with learning curve themselves..
Especially if they are focussing on larger teams or to solve more comprehensive software development. So time savings may go out of the window, for achieving just a simple authentication task. I suppose it's worth investigating time savings vs. effort to set-up per tool.
I used okta (auth0) before and it wasn't too hard to set up, especially with their SDK and using something standard such as OIDC. But I just looked at their pricing and their free tier only includes 7,500 users 😬
These days, I use Appwrite (disclaimer: I am an employee but I was a contributor before that) and our Starter Plan in includes 75,000 users. You can also self host Appwrite for free!
Yep that is a big difference. To be honest, I have no idea how these two compare, but I guess it's more than just the number of free tier users?
I could see myself pay for a service that has some valuable features over a cheaper but trimmed down one. Especially if those features give me e.g. certain value/insight I'm looking for.
I want to integrate into any project, SaaS, and backend. I code in JavaScript and Python, using Node.js, Nest.js, and Django. For databases, I work with ORM, Prisma, MySQL, and PostgreSQL. If any startup is interested, I am happy to work for free. We can discuss to gauge my level and review the projects I have worked on. I am at an intermediate level.
Can my fellow community members teach me how to go about setting up a authentication service on my website? Thank you. Links to simple resources would be helpful.