You got offended by the title because you are Next-Auth fan boy? You do not even watch the whole video. There are a lot of good alternatives to Next-Auth just so you know 😅.
@@randomforest_dev Not even! Actually I'm grateful for this video because I needed something like this since I want to use GO for my backends, this seems to give me more control to achieve this than next auth.
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.
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.
The maintainer of authjs/next-auth is a very self righteous, cocky and overconfident guy. We need to stop putting library authors on a pedestal just because they created a library. The guy talks down on people and feels like he's the person that should guide the industry on "bad practices".
Lucia is great, and the accompanying "Copenhagen book" is a good reference for implementing auth. I actually removed Lucia itself and implemented my own flows based on it, for more flexibility. Also, my opinion on SSO, Soc-2 etc. is that that's only relevant when working with enterprise customers. That's when you should consider a 3rd party service.
Pilcrow is a legend! Crazy that they're only like 20 years old or something, the stuff they've been putting out is so good. Definitely learning a lot about auth
I've been using lucia for almost 3 months now and I really like it, it helped me understand how auth really works. But now that I understand, I don't see too much value on lucia: it's just creating and managing sessions on your db which isn't hard at all. At this point it might be better to just own the whole flow and be fully flexible. I see value in Arctic/Oslo though.
yeah, I did start to wonder that as I was using it. It seems mainly useful for just creating the cookie, creating the session, deleting the session, etc, but yes that wouldn't be much extra work to just do it myself
The only thing I don't like about Lucia is they have implemented a custom algorithm for generating IDs (based on the native crypto module, but custom nonetheless), and while you can choose your ID for your business tables (users, groups, etc) you can't for the sessions table. Either you have to use their method for all your database IDs or you will have two different kinds of IDs on your db. Not a big deal I know, but it would be nice if they used a standard like UUID or let us bring our own one
Just go for oslo without Lucia, its a breeze. Session management is not that hard and all this adapter hell all new libraries come with is just nonsense
tbh , it isn't that hard , i've been using next auth with credentail based login with rbac , seems to work just fine , you just have to set it up in the proper way . But they could work on the docs though.
This was extremely helpful for my use case. My application required Credentials based login, and then a feature where a user could sync multiple Google accounts to their profile. This made auth strategies with NextAuth a mess, or at least non-intuitive since I'm not an expert on auth implementations. Lucia seems to be exactly what I needed. Your video could not have been timed better, I was literally assigned this the day before you published this video lol. Thank you for your straight forward content!
on a real larger app I'd use redis or upstash. There are a lot of libraries that already exist that allow you to hook into redis and track request counts per user / IP then deny them access if they go over a limit.
What are you doing when a user regsiters but has not verified his account? I mean, do you allow the account to be re-registered when not verified? Any thoughts?
Do you have an example on how to fix the JWT callback to get access to data from authorize in NextAuth? It does not get the data that is passed from my authorize function...
I think in the session callback you’ll be sent a user object that you need to use to attach info to the jwt. You also much use a jwt strategy, you can’t use a database strategy
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!!
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.
when you click on sign in with google then why it will display "See the 3 services ". It looks bad, when some UA-camrs make their video on next auth then on consent screen page it will be user friendly, not like your consent screen page.
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
Did you run into issues with next.js middleware with lucia. My issue with lucia which i ran into few weeks ago (not sure if there is a solution for it) was trying to set up protected pages in the middleware, where i wanted to redirect the user to the auth page if they are not logged in, obviously i didn't want to do it manually in every page/API route, but I had problems running lucia in edge runtime, so I had to go with next-auth. Wondering if you have any experience with that.
i am also want to use lucia in my next.js app, but i cant figure out how to get the session in client component other than getting it in the page/server component level and passing it as a props. You will help me a lot if you share with me the solution to this problem.
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.
I totally agree with you. It's interesting that a lot of these libraries are trying to steer people away from using passwords and yet, pretty much every single online service I use (UA-cam, Google, Azure, AWS, etc...) still uses passwords!
Yes because most people don’t do it correctly or make a mistake that leads to their app being compromised. These multi billion or trillion dollar companies funny enough are generally better at doing it correctly
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?
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.
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'm not using JWT strategy. This approach will not work for database strategy. It is indeed trivial if you use next-auth the exact way they indent you to do it. Also I'm not sure why the docs are so bad.
@@WebDevCody Isn't JWT required for CredentialsProvider though? I agree that the docs are pretty obscure, given the claim that they wantsto be the biggest and best auth solution for js/typescript projects
I somehow got it to work. I am using page router if that matters, but you need to add thr session to the callbacks and set up jwt. You also can add role.or whatever to the user, just add it with a default.value then change it later
Rolling your own auth is not recommended as there is a ton of security implementations that goes into things like these that's why there are libraries for things like it
@@WebDevCodyI’ve seen something about using multiple projects in one account with table prefixes in the drizzle config. Kinda what we used to do back in the day, but would be ok for dev. I would love to see a video on how to do this in Drizzle though.
@@WebDevCodeCrush oh yeah I prefix my table even without trying to get multiple projects on the same database. There is a mapper you can pass to the drizzle adapter if you’re using next auth, otherwise I’m not too sure if you can change the session table name with Lucia auth or not.
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😂
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’ll implement that soon, usually you just send an email to the user with a url containing a short lived token. User clicks link, it opens a page where they type in a new password, send that password and token to your api, change their password if the token was valid and not expired
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.
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 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.
Without using jwt strategy, walk me through how I can use their credentials provider? Like provide me a link to a working example, because I’ve tried and it doesn’t work. I guess I’m just reaching the point where email pass login has benefits, and I’d rather not waste my effort using a tool that is so strongly opinionated to use JWT and not have first class support for email pass login
With the info I provided above though I’m sure ChatGPT could get you the rest of the way so you don’t have to wait on me, but again I have no problem implementing it.
@@TheSocialDeveloper I mean for real try to implement it with the database strategy: github.com/nextauthjs/next-auth/issues/10966. it just doesn't work
@@WebDevCody Read the docs and I see where you’re coming from now. You could probably take a hybrid approach between the JWT and sessions but just depends on the amount of effort you want to invest. Is there a reason why you prefer stateful to stateless authentication or are you just trying to ensure that the SSO and credentials flow are in sync in terms of state approaches?
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.
exactly, if they don't provide a way, people will hack a way, and in 1 year we'll just have a bunch of insecure next.js applications and both next.js and next-auth will get a very bad reputation. There is nothing wrong just providing an expected authentication experience out of the box that is done correct. The maintainer is on a power trip.
@@WebDevCodyI got the same impression from reading their stance on credential logins in the documentation a few months back lol. (The power trip thing)
Lucia is pretty great compared to NextAuth, because the logic is not that hidden and it shows you that auth is actually not that hard. I now switched to implementing everything by myself and i recommend everybody to do this at least once.
Develop some critical thinking and the ability to form your own opinions. It's great for setting up Oauth with other providers, but a pain for credentials
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 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
NextAuth is just overly complicated. Like most libraries are! Even lucia is too much for my taste. Lucia uses oslo under the hood which comes from the same author. With oslo alone you can easily create your own auth and if you dont understand how you should just dont do auth on your own.
@@WebDevCody yes, but while it saves some time at the start you will Most likely end up spending more time maintaining It, thats what i felt like atleast. But still, Lucia is pretty nice for prototyping, optimization can be done later, as always. Btw, i enjoy your Videos, even though i dont use nor like nextjs. Your content is pretty nice to watch as it feels Like beeing part of the projects you are working on, kinda like a daily vlog. Keep it going :)
Nextauth have a good amount of features, but I have to agree that their documentation is terrible, it is one of the worse documentations that I have seen. I think only java manages to be worse than them.
If you want to finish your projects, do not watch UA-cam influencers 😅, you'll never finish
You got offended by the title because you are Next-Auth fan boy? You do not even watch the whole video. There are a lot of good alternatives to Next-Auth just so you know 😅.
So true
IMHO, you can do versioning to projects if you want to try new stuff without starting all over. MVP > dangling projects
@@randomforest_dev Not even! Actually I'm grateful for this video because I needed something like this since I want to use GO for my backends, this seems to give me more control to achieve this than next auth.
@@WebDevCody Thats a bold assumption :(
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.
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.
they don't recommend it because they want you to use JWT so that their auth works on EDGE so that you use VERCEL
@@WebDevCody Oh RIIIGHT I forgot about that, session based auth doesn't work properly on EDGE right?
The maintainer of authjs/next-auth is a very self righteous, cocky and overconfident guy. We need to stop putting library authors on a pedestal just because they created a library. The guy talks down on people and feels like he's the person that should guide the industry on "bad practices".
@@nasko235679 it doesn't?. How so
@@nasko235679 I am not familiar with the libraries, but why would session not work on the edge?
Lucia is great, and the accompanying "Copenhagen book" is a good reference for implementing auth. I actually removed Lucia itself and implemented my own flows based on it, for more flexibility. Also, my opinion on SSO, Soc-2 etc. is that that's only relevant when working with enterprise customers. That's when you should consider a 3rd party service.
Pilcrow is a legend! Crazy that they're only like 20 years old or something, the stuff they've been putting out is so good. Definitely learning a lot about auth
I've been using lucia for almost 3 months now and I really like it, it helped me understand how auth really works. But now that I understand, I don't see too much value on lucia: it's just creating and managing sessions on your db which isn't hard at all. At this point it might be better to just own the whole flow and be fully flexible. I see value in Arctic/Oslo though.
yeah, I did start to wonder that as I was using it. It seems mainly useful for just creating the cookie, creating the session, deleting the session, etc, but yes that wouldn't be much extra work to just do it myself
The only thing I don't like about Lucia is they have implemented a custom algorithm for generating IDs (based on the native crypto module, but custom nonetheless), and while you can choose your ID for your business tables (users, groups, etc) you can't for the sessions table. Either you have to use their method for all your database IDs or you will have two different kinds of IDs on your db. Not a big deal I know, but it would be nice if they used a standard like UUID or let us bring our own one
@@WebDevCody also that way you don't have to worry about adapters and db schema being a certain way
Just go for oslo without Lucia, its a breeze. Session management is not that hard and all this adapter hell all new libraries come with is just nonsense
what about refresh tokens?
Next-auth's credentials setup is pain in the a**.
@jacwida dont bother, next week he will think its good again
@@o_glethorpe actually nah
@@o_glethorpe wow how dare you. Sometimes I stick to something like deploying to VPs
Thank you
tbh , it isn't that hard , i've been using next auth with credentail based login with rbac , seems to work just fine , you just have to set it up in the proper way . But they could work on the docs though.
I had spend 2 days to implement email pass in next auth, At that point I just realised why I’m wasting my time
Same man.same.
This was extremely helpful for my use case. My application required Credentials based login, and then a feature where a user could sync multiple Google accounts to their profile. This made auth strategies with NextAuth a mess, or at least non-intuitive since I'm not an expert on auth implementations. Lucia seems to be exactly what I needed.
Your video could not have been timed better, I was literally assigned this the day before you published this video lol. Thank you for your straight forward content!
have you thought about rate limiting? would love to see a tutorial on that
on a real larger app I'd use redis or upstash. There are a lot of libraries that already exist that allow you to hook into redis and track request counts per user / IP then deny them access if they go over a limit.
after 1 month next-auth setup, i give up, planning to move to lucia as well.
next-auth is the most painful js lib i have ever use.
What are you doing when a user regsiters but has not verified his account? I mean, do you allow the account to be re-registered when not verified? Any thoughts?
Do you have an example on how to fix the JWT callback to get access to data from authorize in NextAuth? It does not get the data that is passed from my authorize function...
I think in the session callback you’ll be sent a user object that you need to use to attach info to the jwt. You also much use a jwt strategy, you can’t use a database strategy
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!!
the app router hot reload is doing good now
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.
when you click on sign in with google then why it will display "See the 3 services ". It looks bad, when some UA-camrs make their video on next auth then on consent screen page it will be user friendly, not like your consent screen page.
if I am using strapi, what is the best way to actually do authentication? I am also using next.14 >
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
Did you run into issues with next.js middleware with lucia. My issue with lucia which i ran into few weeks ago (not sure if there is a solution for it) was trying to set up protected pages in the middleware, where i wanted to redirect the user to the auth page if they are not logged in, obviously i didn't want to do it manually in every page/API route, but I had problems running lucia in edge runtime, so I had to go with next-auth. Wondering if you have any experience with that.
What you think about Kinde? it looks nice and easy to setup
i am also want to use lucia in my next.js app, but i cant figure out how to get the session in client component other than getting it in the page/server component level and passing it as a props. You will help me a lot if you share with me the solution to this problem.
just make a wrapper server component
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.
I love this channel. Just a guy showing you how hes doing interesting things and why. Easy to watch and useful.
Keep it up
Glad you enjoy it!
I totally agree with you. It's interesting that a lot of these libraries are trying to steer people away from using passwords and yet, pretty much every single online service I use (UA-cam, Google, Azure, AWS, etc...) still uses passwords!
Yes because most people don’t do it correctly or make a mistake that leads to their app being compromised. These multi billion or trillion dollar companies funny enough are generally better at doing it correctly
Have you a session invalidation exemple with lucia-auth ?
I think you can just delete all the sessions by userId from your database.
Will the wdc starter kit also move to lucia? In the landing page it still says next-auth
Yeah I need to update the landing page
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?
I think I hard coded it to 10,000.
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.
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
where in the docs is this explained?
I'm not using JWT strategy. This approach will not work for database strategy. It is indeed trivial if you use next-auth the exact way they indent you to do it. Also I'm not sure why the docs are so bad.
@@WebDevCody btw can we have a short video / short content on why you chose database strategy instead of jwt?
@@WebDevCody Isn't JWT required for CredentialsProvider though? I agree that the docs are pretty obscure, given the claim that they wantsto be the biggest and best auth solution for js/typescript projects
@@PraiseYeezus I don't think it is, had to figure the order out myself 🤣
I somehow got it to work. I am using page router if that matters, but you need to add thr session to the callbacks and set up jwt. You also can add role.or whatever to the user, just add it with a default.value then change it later
Why don't you implement your own authentication/authorization instead of jumping from one library to another?
that's also an option if I want to waste my time doing that
@@WebDevCody Isn't switching libraries already a waste of time?
👀
@@adspacheco we can't compare that to writing something from scratch
Rolling your own auth is not recommended as there is a ton of security implementations that goes into things like these that's why there are libraries for things like it
@HorizonHuntxr there's libraries for countless things you can do yourself
wouldnt bcrypt be better than crypto for passwords?
Crypto is standard to node. I’d personally use standard libraries over third party ones
@@WebDevCody understandable
Hello, you have multiple websites with drizzle how do you have multiple databases is it for free ?
supabase supports 2 free projects, the other is hosted in railway which costs money
@@WebDevCodyI’ve seen something about using multiple projects in one account with table prefixes in the drizzle config. Kinda what we used to do back in the day, but would be ok for dev. I would love to see a video on how to do this in Drizzle though.
@@WebDevCodeCrush oh yeah I prefix my table even without trying to get multiple projects on the same database. There is a mapper you can pass to the drizzle adapter if you’re using next auth, otherwise I’m not too sure if you can change the session table name with Lucia auth or not.
Can you please do a lucia auth in a mern stack
How is Lucia going for you now😂. Time to make another video on how it actually sucks.
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😂
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 agree, but so many people are so anti third party service.
how do you deal with forget password ?
I’ll implement that soon, usually you just send an email to the user with a url containing a short lived token. User clicks link, it opens a page where they type in a new password, send that password and token to your api, change their password if the token was valid and not expired
can you please try it with convex please 🙏
try what with convex, next-auth?
name of your vscode theme?
bearded theme - stained blue
@@MarkMendoza-v6h Thank you! I have been searching for this theme name for a while.
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.
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.
It doesn’t work for database strategy
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.
Without using jwt strategy, walk me through how I can use their credentials provider? Like provide me a link to a working example, because I’ve tried and it doesn’t work. I guess I’m just reaching the point where email pass login has benefits, and I’d rather not waste my effort using a tool that is so strongly opinionated to use JWT and not have first class support for email pass login
With the info I provided above though I’m sure ChatGPT could get you the rest of the way so you don’t have to wait on me, but again I have no problem implementing it.
@@TheSocialDeveloper I mean for real try to implement it with the database strategy: github.com/nextauthjs/next-auth/issues/10966. it just doesn't work
@@WebDevCody Read the docs and I see where you’re coming from now. You could probably take a hybrid approach between the JWT and sessions but just depends on the amount of effort you want to invest. Is there a reason why you prefer stateful to stateless authentication or are you just trying to ensure that the SSO and credentials flow are in sync in terms of state approaches?
ive used lucia-auth for a few months now. love it. whats that maintenance.tsx file? :D
Had lucia on my list to try for a while, I like the extra control compared to next Auth
How about Kinde auth?
I haven’t tried it
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.
exactly, if they don't provide a way, people will hack a way, and in 1 year we'll just have a bunch of insecure next.js applications and both next.js and next-auth will get a very bad reputation. There is nothing wrong just providing an expected authentication experience out of the box that is done correct. The maintainer is on a power trip.
@@WebDevCodyI got the same impression from reading their stance on credential logins in the documentation a few months back lol. (The power trip thing)
How about Clerk?
I like clerk a lot, but this is for a starter kit where I want to limit third party services
Hey Cody, can we maybeee expect some Remix content? 👉👈
Good job babe!!!! I’m first!!! Finally again haha
Lucia is pretty great compared to NextAuth, because the logic is not that hidden and it shows you that auth is actually not that hard. I now switched to implementing everything by myself and i recommend everybody to do this at least once.
oh, it's so messy, when you try to add multiple of these. Especially hostile ones like Twitter...
But you've spent years telling us to use it, and now we aren't supposed to??
it is your choice to make, isn't it?
Develop some critical thinking and the ability to form your own opinions. It's great for setting up Oauth with other providers, but a pain for credentials
Why not supabase?
don't want to depend on a service for auth on a starter kit
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 💯💯💯
True but at least I’d own the abstraction and be able to customize it as needed
@@WebDevCody agree 💯
remix with remix-auth is also nice
Thank God for clerk js
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...
very much a next.js problem. Other frameworks, like Adonisjs already have auth provided out of the box.
And now Lucia is deprecated and not covered anymore 🤣
This is also why i never used next-auth...
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
Table gf_session should be called date
Don’t forgot to remove those console.logs 😂
Classic case of devs making stuff for themselves not for customers lol
Your starterkit seems like too complex. Definitely you should call it finisherkit
I see we have a twitter fan
Switch to Nuxt
move back to next-auth because lucia is getting deprecated 😂😂😂😂
Kinde✨️
Clerk > All Auth library
Have you ever tried AuthKit by WorkOS?
Nextjs is useless without websockets
aaand it's deprecated hahah :(
Bruh
@@WebDevCody yeah man :(
@@WebDevCodywhat will you use next?
Better-Auth
NextAuth is just overly complicated. Like most libraries are! Even lucia is too much for my taste. Lucia uses oslo under the hood which comes from the same author. With oslo alone you can easily create your own auth and if you dont understand how you should just dont do auth on your own.
agreed, I mean the main thing lucia provides is saving me 30 minutes storing / deleting the sessions from the database, and creating cookies.
@@WebDevCody yes, but while it saves some time at the start you will Most likely end up spending more time maintaining It, thats what i felt like atleast. But still, Lucia is pretty nice for prototyping, optimization can be done later, as always.
Btw, i enjoy your Videos, even though i dont use nor like nextjs. Your content is pretty nice to watch as it feels Like beeing part of the projects you are working on, kinda like a daily vlog. Keep it going :)
@@dave-7117 thanks man, glad you enjoy it
Nextauth have a good amount of features, but I have to agree that their documentation is terrible, it is one of the worse documentations that I have seen. I think only java manages to be worse than them.