Auth: which solution for which situation

Next-Auth/Auth.js vs Clerk vs Supabase auth vs firebase auth vs other solutions: for which situations would you pick one over the others? Do you have any preference for other tools (e.g. Auth0, passport.js, etc.)?

MaïeulOP•3/17/23, 2:46 PM

I am not an Auth expert but I have my share of experience since I have tried implementing each of the aforementioned solutions in the past, except for Clerk, but here's my take:

MaïeulOP•3/17/23, 2:47 PM

Next-Auth/Auth.js: when you need complete control at any scale, but at which cost?

I think it can be good when you want total control over your Auth mechanisms. But I don't trust myself enough to understand Auth sufficiently in order to set this up well enough in order for my Auth system to be scalable and secure, and I think other developers should be wary of that too. I personally have had problems in the past with setting up custom claims for access management (roles), and I couldn't set up JWT auth securely. I'm sure Next-Auth/Auth.js can fix these issues and simplify the process eventually, but my take is that you need to understand what you're doing in order to use it properly, or you will spend a lot of time trying to figure it out yourself without knowing for sure that you're not doing anything wrong.

MaïeulOP•3/17/23, 2:47 PM

Clerk: when you want the easiest setup and don’t expect too many users

Though I haven't tried it out, I'm sure Clerk is super easy to implement from what I've seen, and it seems powerful too for User management. The only gotcha for me, and it's a big one, is the price. I think it's less expensive than Auth0, but still, $0.02 for each MAU is very expensive if you have tens of thousands of users and you want your app to be free for your end users. I would probably consider Clerk to build a B2B application, where I wouldn't expect too many users, and where I would need extensive features for user management.

MaïeulOP•3/17/23, 2:47 PM

Firebase: when you need basic auth that can scale for free

If you just need basic Auth with email/password, magic links, Oauth providers, or SMS, Firebase is easy enough to set up and because it’s free for these features (except for SMS but it always costs), I would pick it for most projects that have the potential to reach millions of users. But if you need better User Management, you can upgrade firebase auth with the identity platform, but this cost around 0.0025 to 0.0050 (see: https://cloud.google.com/identity-platform/pricing) per MAU depending on the number of users you have, and this can be expensive too. Another gotcha is that Firebase is proprietary and backed by Google, so you can’t use it in some countries (e.g. China), and you will have to use another solution in conjunction. But for China, you must store your data in Chinese territory anyway, so other solutions won’t help much. Thankfully, you can always extract your users from Firebase if you need to switch to another solution later. It can be hard to migrate passwords though, and this is why I tend to favor magic links over email/password sign-ins (this is what Next-Auth/Auth.js recommends by the way).

MaïeulOP•3/17/23, 2:48 PM

Supabase: when you need basic open-source auth that can scale and more control

Supabase Auth is just like Firebase, the advantage being that you have more control over your database and how they are stored, the disadvantage being that, even though it is not too too expensive, it is not free: $0,00325 per MAU or $325 per 100,000 MAU. Personally, I don’t see much benefits over Firebase, unless you need their Row Level Security (RLS) policies.

MaïeulOP•3/17/23, 2:50 PM

Other solutions: when you have time or money to waste?

I looked into Auth0 a few years ago but found it very expensive and not so easy to implement. I hope it has improved a little since then. I looked into passport.js as well but never managed to set up the jwt strategy, which is what I wanted, and the other strategies didn’t seem much easier to implement. I also quickly looked into Keycloack, but couldn’t wrap my head around it. And I tried rolling out my own solution too, with jwt sessions, and it was just not secure. Please don't do that, it is a huge waste of time.

mrnicericee•3/17/23, 3:13 PM

This is a great summary of each solution! Love how you mentioned each pros and cons. rolling your own auth is great for getting started (as a developer and/or in a project).

IMO, i'd rather hand over auth to someone else. I can focus on what I need/want to do, and auth becomes the easiest thing to implement, plus because auth is their business, they'll either 1. already have what features you need when you need them, or 2. already working on building it out.

MaïeulOP•3/17/23, 3:19 PM

Thanks! I didn't think I'd write so much in the first place

MaïeulOP•3/17/23, 3:20 PM

But yeah, handling auth yourself is totally like reinventing the wheel

mrnicericee•3/17/23, 3:20 PM

btw, if you haven't already make this into an article write it up!

MMaïeul But yeah, handling auth yourself is totally like reinventing the wheel

mrnicericee•3/17/23, 3:23 PM

it is, and tbh I still recommend at least trying to build out your own auth when starting out (or want to know how auth solutions work). You learn best when things aren't working think

plus you get to understand authorization vs authentication

Mmrnicericee it is, and tbh I still recommend at least trying to build out your own auth when...

MaïeulOP•3/17/23, 3:25 PM

Totally agree on that

Zan•3/17/23, 8:44 PM

What would be the limitations on scaling with nextauth?

Zan•3/17/23, 8:45 PM

Unless you need password login I'm having difficulty thinking of any

ZZan What would be the limitations on scaling with nextauth?

barry•3/17/23, 8:51 PM

The fact that you have to handle it is the only one

djcmurphy•3/18/23, 5:22 AM

I ended up using iron-session because it is very barebones and just stores a stateless cookie. the api is decent... bit of work to get it into trpc routes (you have to pass the next req in trpc context) but it allows you to auth a cookie without all the extra baggage. Perfect for internal staff systems where login requirements are different and login providers are not wanted.