I'm finally moving away from Next-Auth

name of your vscode theme?

I've been using both next auth and Lucia at my job and for my personal projects for the past 1.5-2 years. Both of them can do the job of credentials sign in. The main difference is that next auth has a total mess of docs. Next auth requires a bit more work if you need multiple providers + credentials, a custom adapter if your db isn't supported out of the box(in case ya need a db session management). On the other hand Lucia provides clean docs and great support over discord. Depending on the requirements, time, money I swap between the two. My personal opinion on which is better hands down is Lucia. Keep in mind if I remember correctly Lucia needs a db to work where next auth can work with jwt strategy.

Table gf_session should be called date

I like the idea of owning my own auth flow, but have never been able to implement it to my satisfaction and with the level of security that I want. Of course, the password reset flows are always fun to build too. Great learning experience, but like I was told a long time ago, you can do it, but by the time you’re done you’ll realize why you should have just offloaded it to a 3rd party…, and then you’ll be spending all your time supporting it and not the app you were building.

I entirely agree about Next-auth. From the moment I found it I decided I wouldn't be using it. The consumers I'm targeting with my apps distrust google and are very familiar with the email/password setup, just like you said.

Hey Cody, can we maybeee expect some Remix content? 👉👈

I noticed on SignIn that you’re grabbing the user.salt and user.password back from the getUserAccountByEmail SS script when running the verifyPassword function, but I don’t see you using iterations anywhere. Why is that?

Clerk > All Auth library

Had lucia on my list to try for a while, I like the extra control compared to next Auth

Don’t forgot to remove those console.logs 😂

Please Help me out here. In my case, i don't have access to the database. I only have access to the API endpoints (built in another framework ,by another set of devs, on a separate server), that provides tokens for login, all user info and stuff. So my nextJs app consumes data provided by the endpoints. Can i still use Lucia to handle authentication or should i just do the authentication my self. I tried next auth, didn't work out fine because it's very opinionated.

Rolling your own auth is honestly not that hard.
1a. Create a DB table which will hold the necessary details of a user. Assuming that we skip 3rd party auths like Google for now, you would typically just need the following fields: id, email, password, created_at. updated_at, confirmed_at (if you want email confirmation), username (if you want to display usernames instead of emails). Make sure you remember to make fields unique as needed for your requirements.
1b. Create a DB table for storing session info (session id, user id, expiration date). You can make this a bit more nuanced by changing it into a token storage table instead. These tokens can be session ids, reset password tokens, email confirmation tokens, etc. This would even allow you to manually create your own magic link type of sign in. Store the magic link token in the table, send it to the mail provided, when the user clicks the link in their email, exchange that magic link token for a session token.
2. Create the different endpoints for registration, sign in, confirmation (if you need it), sign out.
3. Password validation (password length, capital letters, numbers, lowercase, special characters, password confirmation, etc)
4. Uniqueness constraints (email, username, etc). This makes sure that you don't have duplicate users with potentially the same email and/or username
5. Password hashing (don't do this yourself. use already battle tested solutions such as bcrypt, pbkdf2, argon2). You can either generate a salt and store it along with the user, or just use a server secret and use that instead. I prefer the latter.
6a. Once registration or sign in are done (creating a user, or retrieving a user by verifying the password) you create the session info. Generate a random session id (can be done using crypto random_bytes or any other random string generation tool) and store it in the database.
6b. Put the session id in a cookie and send it back to the client. You are now signed in.
7. On designated requests, check for the session token and validate it. If session token is valid, return whatever that endpoint is supposed to return (either data or redirect). If invalid, return to login page.
8. For signing out, just delete the session cookie data from the request, as well as in the database and redirect the user to the login page (or wherever you want them to go after signing out).

There are of course a couple things I skipped over (such as sending emails, doing reset password, forgot password, etc), but this is the general gist of rolling your own auth.

When I first started using Next auth I was disappointed by the lack of support for credentials so I learned how to do it. It was a long process of learning and in the end I decided password based auth is dumb and I stopped using it

I had never used Next-auth before, but when I first saw it, I realized that being too specialized to a framework and having a shiny website is not good.

I love this channel. Just a guy showing you how hes doing interesting things and why. Easy to watch and useful.
Keep it up

I had spend 2 days to implement email pass in next auth, At that point I just realised why I’m wasting my time

Kinde✨️

Classic case of devs making stuff for themselves not for customers lol

Have you a session invalidation exemple with lucia-auth ?

This is also why i never used next-auth...

Your starterkit seems like too complex. Definitely you should call it finisherkit

have you thought about rate limiting? would love to see a tutorial on that

OMG, this is just painful and it sucks , everything with next-js just makes me cringe!!, am not really a hater but my GOD WHY?? WHY THE PAIN?!, btw, how is the dev hot reload now, it used to suck with the app router, i never tried the pages router!!

can you please try it with convex please 🙏

I love Lucia, I've been using it for a while. I liked that v2.x.x handled user creation and keys for you; In v3 you have to roll your own. This new approach makes it more flexible I suppose, but I liked not having to do that piece for simple username and password login. I've been reluctant to migrate to v3 but I think it's time I do. Their Discord is a great resource if you run into trouble.

Lucia has documentations for other OAuth Providers like Google just go to their V2 documentation in the main website.

Omg Cody. I just spent hours implementing auth with edgedb because of some hackathon, before which I spent a week on a custom implementation of next auth with drizzle, after figuring out a prisma client and auth solution. I may as well roll out with this too... I'm starting to agree with prime that it's probably just better to learn to roll your own auth lol😂

NextAuth was pretty horrible when I tried setting it up. Had it running for a couple of weeks before ripping it out because it just didn't work correctly. It couldn't handle refresh tokens correctly, and it was really messy catching expired sessions across client components, server components, server actions, and an external rest API. Wayyyy too abstracted and the docs were pretty awful for anything but the most trivial of set ups.

I ended up moving auth completely to the restapi backend, which used zitadel of identity management via oauth and express session to set cookies. Next just needs to redirect to login if the backend sends 401 or there's no cookie set. Easy.

Thank God for clerk js

Nextjs is useless without websockets

I love the control over the authentication flow and the "lessons learned" trying it.. but I would never use this at my company.
There is a reason why companies like auth0 exist. The developer experience of next-auth kinda sucks, but at least there is a big community with a lot of plugins. Adding authorization is also easier.. As much I would love to do it on my own, I think the topic is too critical. xD

how do you deal with forget password ?

Dude Cory, I love your videos. You taught me how to generate PDFs with puppeteer and SST. 

But the Credentials provider in next-auth is extremely powerful. I use it for email password but I also use it for phone OTP verifications. Once you understand how it works, and yes that's a big hurdle, the Credentials provider is basically a back door to a very awesome auth system.

I have used both of them. As you said, lucia has lot of duplication of code. You said you can abstract out those parts, but that is the exact thing authjs is doing 😂. So you will end up at authjs somehow. But yeah as you said "Sometimes Duplicate code is okay" agree 💯💯💯

I have to disagree with you on the Next Auth Credentials take. Nextauth has a callbacks section in the documentation explaining what each method does and how to set them up. If you look under the hood of other providers you’ll see they have the same setup. Next Auth doesn’t provide an implementation step directly for the Credentials flow cause they don’t recommend it but they don’t make it any more difficult than setting up third party Oauth either.

oh, it's so messy, when you try to add multiple of these. Especially hostile ones like Twitter...

I use Next-Auth with credentials, and it works through the jwt() and session() callbacks in [...nextauth].

but I agree the lib sucks

You shouldn’t use sha512 for passwords. Lucia has a couple of other libraries (one used for oauth and another one for passwords and other tools) that can help with a variety of proper algorithms to hash passwords

Is the project you are working on github? Would you mind creating a template with your implementation of lucia? Ive read the docs but somehow couldnt get it to work properly especially oauth

wouldnt bcrypt be better than crypto for passwords?

Yeah I don't mind next-auth's stance on credentials login, but would appreciate if they didn't actively prevent you from doing it if you want/need to have it in your app.

Have a big red banner saying you think it's not the optimal/secure way, but at least give a good (secure by default) way to do it. I think them avoiding it will lead to mistakes and people storing plain text passwords in their db just because they don't know better.

I dont like Laravel for a lot of things but at least it has the auth figured out. Its so streamlined that it puts js frameworks to shame...

One thing that made me choose sveltekitover nextjs is the credentials auth implementation without having to use a package

Today I had a chat with the creator of authjs in their discord and he told me that if I wanted real-time authorization management I should go with a "db session" strategy for my credentials provider. When I asked him where the documentation is on that he told me "no, we don't recommend it. if you need it, we think you should implement it with care and consideration, having the right knowledge to do so. People often don't realize that it's more than just the code. bot protection, pw management/rotation, etc. That said, it's fully possible to do it, in like 20 lines of code, if you know what you are doing " . And then he proceeded to gloat about how flexible authjs is. So tldr: "authjs can do it but he won't write any documentation because he's against certain ways of authentication". So weird.

How about Clerk?

Idk, for me lucia seems much more intuitive than next-auth even though I'm seeing this code for the first time. You don't have weird callbacks that you don't know what they do.

I do very similar stuff with solid-start, sst (future/auth) and Google Login (sst GoogleAdapter), lucia is really good with that!

For NextAuth you need to do the db lookup of your user in the authorize callback then the object you return will be passed to the jwt callback and inside there you return the token param of the jwt callback, after that the session callback is run with the session and token able to be destructured from the param, you need to then return the session from this callback.

Perhaps it's not clear in the docs but once you know, it's pretty trivial

I didn't find it that hard to get NextAuth working with the Credentials Provider in my projects.
The whole point of using the Credentials Provider is to let users sign in while it handles all the annoying JWT stuff behind the scenes, which is fantastic.

The account creation process is very individual for each application, which I think is why the NextAuth team hasn't implemented a ready-to-use account creation feature.
I personally just took the time to build a solid registration flow tailored to my needs, along with a flexible role-based User schema that I can now reuse across all my projects.

Nonetheless, I think Lucia might be a better alternative for people who are approaching authentication for the first time, especially because it is less abstract than NextAuth.