Thank you for the tutotial, it's a good one. I just wanted to make a few points. From the security standpoint, the good practice is to have JWT in memory or basically sending through http context and save refresh token in an http only cookie so when a user leaves their browser and comes back again, the application can uses the refresh token to issue a new access token. But, by using your approach, when a user refreshes their browser or closes it they lose both access and refresh tokens and they have to sign in again in order to access the protected area of the application. In SPA applications you use a refresh token in order to issue an access token again after its expiration, so we need to keep it somewhere safe to use it again, otherwise it is pointless to use it. On top of that, when you only use one refresh token in your user's entity and every time you replace it with a new one, then users will not be able to have their multiple devices logged in, because whenever they logs in in each device,then the previous refresh token they used in another device will be replaced with a new one and their another device will be no longer logged in. So we need a user entity that has one to many relationship with a refresh token entity. You can also read more about the security recommendations for access and refresh tokens from the link below if you are interested: dev.to/cotter/localstorage-vs-cookies-all-you-need-to-know-about-storing-jwt-tokens-securely-in-the-front-end-15id
That's a very clear explanation. Thank you so much. Although I just have one naive question... From SPAs, we always send access tokens in headers... How do we know when to send the refresh token to generate new tokens? I mean when the access token is expired it will send an unauthorised (forbidden) exception or something of that sort. Then how do we send the refresh token? Any working example code would be really helpful. Thank you
@@aadispare3673 Late answer here, but actually when you hit a protected route, if the access token has expired you will get an unauthorized exception, so you must catch this exception by hitting the refresh tokens route if the refresh token is not expired too, then try to hit the first route again
Hey. Nice video. Some points of interest. 1. @Injectable tells Nest to reflect on the constructor and see if there are dependencies it needs to inject into it. If there are no dependencies to inject, you don't need the decorator. 2. You can store tokens in local storage on the client, however they are open to an XSS attack and with 7 days (for the refresh token), a lot of damage can be done. I'd suggest storing the refresh token in an http only cookie. This avoids XSS attacks, as attackers won't be able to get access to the cookie. You should also add the "/refresh" path to the cookie too, so the cookie is only sent on requests made to the "/refresh" endpoint.
Thank you a lot for this comment! 1. Yes 100% :) 2. Excellent suggestion, I had a couple of discussions on reddit and we agreed that what you suggest would be the best solution. I will prepare a video on the subject
@@CodeWithVlad I have a question; while I understand the concept and have some practical experience, one thing I'm having difficulty with is determining the best method to implement this with some frontend code.
To learn NestJS Authentication I have seen many videos and I got confuse about JWT but with your video I am pretty clear and the way you explain everything is awesome. Thanks.
This tutorial is excellent. A great teacher, who makes us go deeper into the content through knowledge, good humor, sincerity (because there were no cuts in the moments of code error) and many tips to evolve as developers. Thanks!
Not long and not tedious. That's what tutroial should be. You get the whole idea in one video and then just keep on your coding. Thank you for the tutorial
Not sure if the 15mins delay logout w/ refresh token hash is from who's idea. that's cunningly brilliant. one of the finest JWT tutorials ever. keep up the good work. i totally appreciate your time and effort.
I was trying to find a tutorial for many days that would explain the reason for each thing and not just give me the code. Your tutorial is one of the best I've seen on TH-cam and I'm surprised it's free, congratulations on something so amazing, you earned a subscriber. I hope you can launch courses, I will buy for sure. Hugs from Brazil!
Прекрасное видео! Видно, что в проекте позже был использован Аргон, что тоже круто) Надеюсь увидеть в будущем более продвинутую реализацию, в том числе с функционалом активации аккаунта по почтовому ящику. Спасибо за такой ценный контент!
Спасибо, Влад! Супер комплексный подход! В самом начале долго не мог понять, так какой же стандарт жизни access токена, 15 или 50 минут. Я же дилетант, обычно делал пять часов. ) Просто обычно в слове "fifteen" ударение на последний слог, а слышалось как будто "fifty" с ударением на первый слог. Еще раз спасибо за видео!
Vlad, thank you again. You are really putting a lot of effort into these videos dude and we can see it in your how you are able to tie multiple concepts together in a way that logically flows so well! You have taught us in hours what it takes some years to understand so thank you for literally giving me extra life points! 👏👏👏
Nice tutorial, thanks! Actually it's nice seeing someone experienced mess up a little bit and find the solution on the go, that's how coding really is like.
Hello Vlad, Thanks again for your tutorial and explications that's amazing !! I have one question about the 1:10:25 when you try to spam logout again and again , it's seems to be return a 401 Unauthorized after a first 200 no ? Best.
That was awesome! I'm new with NestJs and started to create my own demos. I've learned almost everything from you. Thank you so much for sharing that much information.
i'm following this tutorial using Mongo instead of Postgres and it's even simpler. i don't know if it's more appropriate but it's easier. just a few issues related to migrate and the id field but other than that, very smooth sailing
This is excellent content 💯. The flow of learning concepts and writing code hits the mark. Major kudos for covering typescript safety, especially for creating custom decorators and explaining the public guards. Thank you, this was an easy subscription from me.
This is elegant, Vlad. You inductively demystify the abstract concepts and made them look simpler for digestion. I look forward to learning the Microservice with NestJs from you. Thanks, Man! 🥰
This is such an amazing video. Glad I stumbled across this. Subscribed. Would be going through the other videos on your channel. And, eager to learn more from you. Thank you so much.
1:16:35 that's because updateMany finds all fields considering rules from 'where' separately.. which means your logout at this moment doesnt even have a user ID, but just resets all the user fields that HAVE hashedRt not null... to null for all users in DB. That's a LOL )
I'm so glad that you are using the same tech stacks as me. Nest.js + Prisma is so powerful. Can you make a video about deployment? I'm so curious about what cloud provider you use and how you handle the deployment.
You're the best! All the things that I know in NestJS are thank to you and your videos, you explain it so well! Now I was wondering, can you make a video on Redis and sessions too?
Hey Vlad, great video! However, I noticed a downside to this approach, if a user signs in in another app/device his first refresh token will stop working, since the hashed refresh token in the DB will be updated at the moment of the second sign in. Lets say you have a web app and a mobile app. A user signs in in the web app and then proceeds to sign in in the mobile app. The moment the user signs in the mobile app his refresh token for the web app will be replaced in the DB with the mobile app's refresh token, later at the moment of requesting new tokens from the web app this will fail and he will have to log in again, which will then cause the same issue but in the mobile app. In other words, a user won't be able to maintain 2 "sessions" in different devices/apps.
Hi and thank you for the explanations which really help to understand JWT and refresh. But we really lose the interesting side of stateless because the logic is designed to handle only one login at a time. If you sign from another device, you lose the previous hash... I think it's better to keep a history per user in redis, a hashmap per user containing all the hashes of refresh tokens and a TTL close to that JWT expirations. This allows you to logout by removing the correct hashes in redis and even to log out all devices by removing the complete hashmap.
But in this scenario, when an access token expires and we call the refresh endpoint, we're updating both tokens. Given this situation, the refresh token expiration wouldn't make sense, right?
Great video but when you logout you probably still will be able to do something in your app for a while (15min), cause you deleted refresh token from the DB, but access token is still legit right?
Agreed. So when you implement other operations - like change-password, you will still be able to change your password after logout... so what is really the best way?
@@donluc007 After a year I can tell that this is a common problem of stateless auth solutions. If you want eliminate this behaviour you need to implement stateful auth via storing session data inside your db, and then checking it on every request. You maybe want to store it in Redis but any rdbms will fit great too
Loved the video! I have a question though, what happens if a user signs in from a different device? or is already signed in there. They will at the very least have to relog once, right?
If the user uses a different devices he will need to log in again, and that would overwrite the refresh token. This approach does not work well with multi devices. Session based authentication would be a better choice for this.
@@CodeWithVlad Gotcha! I actually found a similar solution to yours, where the JWTs aren't stored on the user but rather in a different table. They have expirations added to them, along with an isObsolete field. If one refresh token needs to be refreshed, the old one simply gets set as isObsolete = true and can not be used again. And refresh tokens are also considered obsolete if they expire. This way a user can sign in from different devices (and have multiple refresh tokens). And then you can also add a functionality to remove all the users refresh tokens ( = sign me out from all my devices) I believe this whole strategy is called refresh token rotation, coupled with refresh token reuse detection. The con with this is that its not exactly stateless anymore, which is one of the biggest benefits with JWTs, but its close enough. It only becomes stateless every 15-30 minutes, or however long you put the access token expiry ;p I would probably never have found out about this if it wasn't for your video, so thanks for that!
Awesome tutorial. A Little question. What do you think of creating a new table for the refresh tokens, with user_id, token and expired at instead of storing the token on the Users table? I think this way you could also Let a user connect on multiple devices on the same time. + it will be easier to blacklist them
Thanks Mihai :) That could work, but you will need to add extra logic and hit the primary database more often. The solution in the tutorial will let you connect with multiple devices at the same time, the problem comes when you try to limit the number of devices. In this case you might need to record the device IP source and information. And check if every call is made from the correct device...might need to use redis to store that information :D
@@CodeWithVlad Did I understand correctly that to support multiple devices we need to return the same refresh token for all of them? In other case, when we log in from the phone, the existing token for the user will be overridden and a PC site will fail to refresh the access token. Therefore, I see the login process with the support for multiple devices as: 1) Validate credentials 2) Check if the RT already assigned to the user 3) Update the RT only if it's about to expire 4) Return { AT; RT; } back to the client-side
I've just realized that there is no way to check if the RT is about to expire during the log-in process. Because it's stored as the hashed string, not an object. 🤕
Great video! In your opinion what's your favorite method for storing tokens on the browser side? I've had a lot of issues trying to set them via the server using httpOnly cookies. The cookies come through in the network tab and postman, but just don't get set on subsequent requests in the browser. Checked everything from withCredentials on the axios request to the headers for Access Control Allow origin not being * but the frontend url. Local Storage?
@54:00 I didn't get it why in you hash your rt token? and store it in hashedRt. what is the use of hashed rt? can't it be stored as it is? why hash rt? I understand necessity of hashing passwords...
Nice video, Vlad! Btw, did you try to use autogenerated prisma DTOs? Do you know how we can validate, cover in documentation (and all that stuff) them by any chance?
Same thing with me. I even copied all the code from /src and package.json in the github repo to be sure. I always keep getting a "[Nest] 529984 - 02/26/2022, 11:43:39 PM ERROR [ExceptionsHandler] Cannot read property 'sub' of undefined TypeError: Cannot read property 'sub' of undefined" error
@@vladgoeswild That worked really well. Thank you! I just had another strange error in a different Nest app and that was also the problem there. Great video, thank you so much!
Thank you for the tutotial, it's a good one. I just wanted to make a few points. From the security standpoint, the good practice is to have JWT in memory or basically sending through http context and save refresh token in an http only cookie so when a user leaves their browser and comes back again, the application can uses the refresh token to issue a new access token. But, by using your approach, when a user refreshes their browser or closes it they lose both access and refresh tokens and they have to sign in again in order to access the protected area of the application. In SPA applications you use a refresh token in order to issue an access token again after its expiration, so we need to keep it somewhere safe to use it again, otherwise it is pointless to use it. On top of that, when you only use one refresh token in your user's entity and every time you replace it with a new one, then users will not be able to have their multiple devices logged in, because whenever they logs in in each device,then the previous refresh token they used in another device will be replaced with a new one and their another device will be no longer logged in. So we need a user entity that has one to many relationship with a refresh token entity. You can also read more about the security recommendations for access and refresh tokens from the link below if you are interested:
dev.to/cotter/localstorage-vs-cookies-all-you-need-to-know-about-storing-jwt-tokens-securely-in-the-front-end-15id
That's a very clear explanation. Thank you so much. Although I just have one naive question... From SPAs, we always send access tokens in headers... How do we know when to send the refresh token to generate new tokens?
I mean when the access token is expired it will send an unauthorised (forbidden) exception or something of that sort. Then how do we send the refresh token?
Any working example code would be really helpful. Thank you
@@aadispare3673
checkout this tutorial by Dave Gray th-cam.com/video/4TtAGhr61VI/w-d-xo.html
@@aadispare3673 Late answer here, but actually when you hit a protected route, if the access token has expired you will get an unauthorized exception, so you must catch this exception by hitting the refresh tokens route if the refresh token is not expired too, then try to hit the first route again
@@qunther makes sense mate. Thank you 😊
Cool!
I like that you don't cut out the way you look for bugs in the code. It helps to keep track of the way you think when something goes wrong
Hey. Nice video. Some points of interest.
1. @Injectable tells Nest to reflect on the constructor and see if there are dependencies it needs to inject into it. If there are no dependencies to inject, you don't need the decorator.
2. You can store tokens in local storage on the client, however they are open to an XSS attack and with 7 days (for the refresh token), a lot of damage can be done. I'd suggest storing the refresh token in an http only cookie. This avoids XSS attacks, as attackers won't be able to get access to the cookie. You should also add the "/refresh" path to the cookie too, so the cookie is only sent on requests made to the "/refresh" endpoint.
Thank you a lot for this comment! 1. Yes 100% :) 2. Excellent suggestion, I had a couple of discussions on reddit and we agreed that what you suggest would be the best solution. I will prepare a video on the subject
Can the mobile client access the cookie if the refresh token is stored in cookie with httponly?
@@ahmadnabil5779 No. That's the reason why there are httponly cookies, so clients can't mess with them.
This is the greatest guide to understanding JWT + refresh! Thank you so much, it really helped me really nail down this concept and practice!
Thanks a lot! It makes my day :)
Please don't forget to use argon2 instead of bcrypt (check the pinned comment)
@@CodeWithVlad I have a question; while I understand the concept and have some practical experience, one thing I'm having difficulty with is determining the best method to implement this with some frontend code.
To learn NestJS Authentication I have seen many videos and I got confuse about JWT but with your video I am pretty clear and the way you explain everything is awesome.
Thanks.
This tutorial is excellent.
A great teacher, who makes us go deeper into the content through knowledge, good humor, sincerity (because there were no cuts in the moments of code error) and many tips to evolve as developers.
Thanks!
Not long and not tedious. That's what tutroial should be. You get the whole idea in one video and then just keep on your coding. Thank you for the tutorial
You came here and wondering is it worth watching this video? Absolutely!
Thanks, Vlad!
This is amazing tutorial 🙌,
I remember before watching the video I had implement Auth-JWT and it took 3 days to understand and implement.
me recognizing the errors before vlad does proves i m getting better😂 thanks for the explanation tho i needed this
Not sure if the 15mins delay logout w/ refresh token hash is from who's idea. that's cunningly brilliant. one of the finest JWT tutorials ever. keep up the good work. i totally appreciate your time and effort.
What a masterclass on the subject! Thank you really much for publishing this video!
Thanks for this wonderful tutorial! It was great understanding refresh tokens along with Nestjs at the same time
I was trying to find a tutorial for many days that would explain the reason for each thing and not just give me the code. Your tutorial is one of the best I've seen on TH-cam and I'm surprised it's free, congratulations on something so amazing, you earned a subscriber. I hope you can launch courses, I will buy for sure. Hugs from Brazil!
one of the best videos in authentication using refresh tokens
Прекрасное видео! Видно, что в проекте позже был использован Аргон, что тоже круто) Надеюсь увидеть в будущем более продвинутую реализацию, в том числе с функционалом активации аккаунта по почтовому ящику. Спасибо за такой ценный контент!
Awesome. i followed this exciting tutorial to build authentication for my own project. Thank you
Great tutorials you make. Congrats mate! Please covers specs and integration testing.
All planned :)
The video on integration testing will be released 9am today :)
Thank you very much for showing the context and how it is actually done in a real project :)
wow - well done Vlad, one of the most comprehensive tutorials / real course, thanks a bunch for your effort and for sharing this knowledge!
Спасибо, Влад! Супер комплексный подход! В самом начале долго не мог понять, так какой же стандарт жизни access токена, 15 или 50 минут. Я же дилетант, обычно делал пять часов. ) Просто обычно в слове "fifteen" ударение на последний слог, а слышалось как будто "fifty" с ударением на первый слог. Еще раз спасибо за видео!
Забавно, я тоже об этом думал, но не стал писать, думал непринципиально, но оказывается кого-то это даже путает)
Can't believe I made it all the way to the end!! Thanks so much.
Thank you so much I finally searched all over the Internet
Tnak you! :D
Wish I found your video few days back. Great explanation, one of the best I heard & actually understood. Many thanks Vlad.
Massive thanks for this wonderful video. You saved me days! Vlad, I wish you to thrive in your career :)
Man... This is actually one of the best tutorial I've ever watched ! You're a really good teacher, thanks a lot !
You are awesome. You are making me to love nestjs more. Thank you sensei 😊
Vlad aka darslariz juda zo'r (from Uzbekistan)
Vlad, thank you again. You are really putting a lot of effort into these videos dude and we can see it in your how you are able to tie multiple concepts together in a way that logically flows so well! You have taught us in hours what it takes some years to understand so thank you for literally giving me extra life points! 👏👏👏
Thank you a lot Christopher!
Vlad is the best tutor for me
Nice tutorial, thanks! Actually it's nice seeing someone experienced mess up a little bit and find the solution on the go, that's how coding really is like.
this is awesome , this is best tutorial i have seen for jwt authentication on youtube
Vlad, loved your video on NextJS on Free code camp. Thank you. Really appreciate it.
Hello Vlad,
Thanks again for your tutorial and explications that's amazing !!
I have one question about the 1:10:25 when you try to spam logout again and again , it's seems to be return a 401 Unauthorized after a first 200 no ?
Best.
Hello did you solve it? I am trying to figure out where the issue is!
This has been by far the best tutorial I have seen about authentication in nest with jwt, congratulations!
Thank you! 😊
I think this is the best tutorial for auth flow. Thanks!
you are a GOD i watched so many tutorials and yours is the only one that actually works, 🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻🙏🏻
Thank you!
Just helped me do the first task in my internship!
Thxxxx
Glad to hear that Ali!
Best video I've seen so far for the JWT implementation in Nest Js. Thanks Vlad.
Subscribed :)
That was awesome! I'm new with NestJs and started to create my own demos. I've learned almost everything from you. Thank you so much for sharing that much information.
Glad to help!
Thank you, very nice tutorial, i'll try to implement this with redis too.
Sorry for my english and thank you again.
i'm following this tutorial using Mongo instead of Postgres and it's even simpler. i don't know if it's more appropriate but it's easier. just a few issues related to migrate and the id field but other than that, very smooth sailing
Thanks this is the type of quality tutorials I want to see on TH-cam!
More to come!
You can replace 60 * 60 * 24 * 7 in expiresIn with string '7d'/'15m'/'1w' etc...
This is excellent content 💯. The flow of learning concepts and writing code hits the mark. Major kudos for covering typescript safety, especially for creating custom decorators and explaining the public guards. Thank you, this was an easy subscription from me.
I'm glad you loved it! Please don't forget to use argon2 instead of bcrypt (check the pinned comment)
Кекаю с каждого "МЫТАДАТА" (metadata) произнесенного на протяжение видео)) Но да, за гайд респект, очень подробно всё и это прекрасно)
haha :)
Very nice video. But get very complicated after some time. :P Thank you Vlad
Amazing Man! I just followed and implemented AT & RT. Yuhuuu....Thanks...!
This is elegant, Vlad. You inductively demystify the abstract concepts and made them look simpler for digestion. I look forward to learning the Microservice with NestJs from you.
Thanks, Man! 🥰
Aaah microservices, I will get to them soon. Need to first provide content on sessions and graphql. :) Thank you Akeren, much appreciated!
This is such an amazing video. Glad I stumbled across this. Subscribed. Would be going through the other videos on your channel. And, eager to learn more from you.
Thank you so much.
Best learning content and teacher i ever seen!
It was good Christmas with this tutorial , thanks
Thank you so much, very clear and complete
Excellent tutorial, Its very helpful. Thank you very much Boss
thanks for tutorial, you explained very well and easily help me a lot.
Thank you for Excellent tutorial. Yes of course I like to understand testing techniques too.
Thanks
I'm glad you loved it! Please don't forget to use argon2 instead of bcrypt (check the pinned comment)
Thank you so much bro. This is very helpful for me and everyone
Super detailed video, thanks. It would be cool if you showed how to add Google authorization to this
00:00:00 Introduction
00:19:23 Database migration
1:16:35 that's because updateMany finds all fields considering rules from 'where' separately.. which means your logout at this moment doesnt even have a user ID, but just resets all the user fields that HAVE hashedRt not null... to null for all users in DB. That's a LOL )
A better version
async logout(userId: number): Promise {
await this.prisma.user
.update({
where: {
id: userId,
hashedRt: {
not: null,
},
},
data: {
hashedRt: null,
},
})
.catch((error) => {
if (error instanceof PrismaClientKnownRequestError) {
// prevent call on logout if hash_rt is null
if (error.code === 'P2025') {
throw new ForbiddenException('Access Denied');
}
}
throw error;
});
return true;
}
Excelente, es la mejor explicación que he encontrado. Te lo agradezo mucho
I just want to say this is a blessing, thank you, excellent
Great tutorials! Explained clearly with a very practical project! Thanks a lot for your sharing!
Looking forward to your new videos about anything :D
This tutorial is excellent.
Thank you very much
I'm so glad that you are using the same tech stacks as me. Nest.js + Prisma is so powerful. Can you make a video about deployment? I'm so curious about what cloud provider you use and how you handle the deployment.
Hey! Thank you for your comment and suggestion. This topic is definitely planned! For deployment I am using aws and hetzner cloud
@@CodeWithVlad im waiting :D
Was here for the refresh function part... Ends up watching the whole video ! Thank you for all the tips !
Can you explain why are you using index.ts ?
Vlad, thanks for the great and awesome content.
Now, which theme are u using ? haha
You're the best! All the things that I know in NestJS are thank to you and your videos, you explain it so well! Now I was wondering, can you make a video on Redis and sessions too?
Hey Vlad, great video! However, I noticed a downside to this approach, if a user signs in in another app/device his first refresh token will stop working, since the hashed refresh token in the DB will be updated at the moment of the second sign in. Lets say you have a web app and a mobile app. A user signs in in the web app and then proceeds to sign in in the mobile app. The moment the user signs in the mobile app his refresh token for the web app will be replaced in the DB with the mobile app's refresh token, later at the moment of requesting new tokens from the web app this will fail and he will have to log in again, which will then cause the same issue but in the mobile app. In other words, a user won't be able to maintain 2 "sessions" in different devices/apps.
Yeah, so you need to store tokens separated from users table
You're amazing dude, I really appreciate it. You helped me out so much!
Muchas gracias hermano, bendiciones. He aprendído mucho y quiero que sepas que me estouy dedicando al back-end.
Hi and thank you for the explanations which really help to understand JWT and refresh. But we really lose the interesting side of stateless because the logic is designed to handle only one login at a time. If you sign from another device, you lose the previous hash... I think it's better to keep a history per user in redis, a hashmap per user containing all the hashes of refresh tokens and a TTL close to that JWT expirations. This allows you to logout by removing the correct hashes in redis and even to log out all devices by removing the complete hashmap.
At that point you might as well use sessions.
@@nobytes2 if the client handle it ;)
WOW, very interesting, please, keep going with videos like this!
Thanks, will do!
this is pure gold! Thank you so much
Thank you
This tutorial is more then excellent.
Thank you, it was an incredible tutorial
Great tutorial 🔥👏 please do one with sessions as well
A lot of people asking for sessions, seem like I don't have the choice than to make a video about that :)
But in this scenario, when an access token expires and we call the refresh endpoint, we're updating both tokens. Given this situation, the refresh token expiration wouldn't make sense, right?
Vlad keep going! Amazing stuff
was looking for something like this!
Amazing!
Thank you so much! Very useful video
You're awesome. Thank for this tutorial. Btw, what do you use autocomplete in command line ?
Thanks for nice tutorial
But i have a question
Do. We need to store refresh token in client side also?
Thank for the course, i did all with you, i have a question, why don't delete de hast to, when do a logout???
Awesome tutorial. Thank you so much! Can you please make a tutorial about CICD with NestJs and Prisma.
Thank you for the compliment and the suggestion. It’s an interesting topic. I will see if i can cover it in a future video.
Super detailed and useful examples !❤
Thank you! 😃
Great video but when you logout you probably still will be able to do something in your app for a while (15min), cause you deleted refresh token from the DB, but access token is still legit right?
i was also in doubt about this
Agreed. So when you implement other operations - like change-password, you will still be able to change your password after logout... so what is really the best way?
@@donluc007 After a year I can tell that this is a common problem of stateless auth solutions. If you want eliminate this behaviour you need to implement stateful auth via storing session data inside your db, and then checking it on every request. You maybe want to store it in Redis but any rdbms will fit great too
Loved the video! I have a question though, what happens if a user signs in from a different device? or is already signed in there.
They will at the very least have to relog once, right?
If the user uses a different devices he will need to log in again, and that would overwrite the refresh token. This approach does not work well with multi devices. Session based authentication would be a better choice for this.
@@CodeWithVlad Gotcha! I actually found a similar solution to yours, where the JWTs aren't stored on the user but rather in a different table.
They have expirations added to them, along with an isObsolete field. If one refresh token needs to be refreshed, the old one simply gets set as isObsolete = true and can not be used again. And refresh tokens are also considered obsolete if they expire.
This way a user can sign in from different devices (and have multiple refresh tokens). And then you can also add a functionality to remove all the users refresh tokens ( = sign me out from all my devices)
I believe this whole strategy is called refresh token rotation, coupled with refresh token reuse detection.
The con with this is that its not exactly stateless anymore, which is one of the biggest benefits with JWTs, but its close enough. It only becomes stateless every 15-30 minutes, or however long you put the access token expiry ;p
I would probably never have found out about this if it wasn't for your video, so thanks for that!
@@christoffer1125 Hi, It would be very helpful If you can share the link here. Anyway this approach is awesome.
Amazing tutorial, so glad I found this
Awesome tutorial. A Little question. What do you think of creating a new table for the refresh tokens, with user_id, token and expired at instead of storing the token on the Users table? I think this way you could also Let a user connect on multiple devices on the same time. + it will be easier to blacklist them
Thanks Mihai :) That could work, but you will need to add extra logic and hit the primary database more often. The solution in the tutorial will let you connect with multiple devices at the same time, the problem comes when you try to limit the number of devices. In this case you might need to record the device IP source and information. And check if every call is made from the correct device...might need to use redis to store that information :D
@@CodeWithVlad Thanks a lot. I was really looking for a tutorial like this. And i love the fact that you used prisma😬
@@mihaiandrei434 Thanks mate. Prisma rocks!
@@CodeWithVlad Did I understand correctly that to support multiple devices we need to return the same refresh token for all of them? In other case, when we log in from the phone, the existing token for the user will be overridden and a PC site will fail to refresh the access token.
Therefore, I see the login process with the support for multiple devices as:
1) Validate credentials
2) Check if the RT already assigned to the user
3) Update the RT only if it's about to expire
4) Return { AT; RT; } back to the client-side
I've just realized that there is no way to check if the RT is about to expire during the log-in process. Because it's stored as the hashed string, not an object. 🤕
thank you so much Vlad
but can you make an in dept tutorial on session as well
incoming :)
Great video! In your opinion what's your favorite method for storing tokens on the browser side? I've had a lot of issues trying to set them via the server using httpOnly cookies. The cookies come through in the network tab and postman, but just don't get set on subsequent requests in the browser. Checked everything from withCredentials on the axios request to the headers for Access Control Allow origin not being * but the frontend url.
Local Storage?
Wow, that's great.
@54:00 I didn't get it why in you hash your rt token? and store it in hashedRt. what is the use of hashed rt? can't it be stored as it is? why hash rt? I understand necessity of hashing passwords...
Great video Vlad 👌🏻👌🏻👌🏻👌🏻👌🏻
Nice video, Vlad!
Btw, did you try to use autogenerated prisma DTOs? Do you know how we can validate, cover in documentation (and all that stuff) them by any chance?
I was looking for this, thanks! 🙌
At 1:08:43, how is req.user populated? It shows undefined for me.
Do you have the jwt strategy and is it imported as provider in the auth module?
Same thing with me. I even copied all the code from /src and package.json in the github repo to be sure.
I always keep getting a
"[Nest] 529984 - 02/26/2022, 11:43:39 PM ERROR [ExceptionsHandler] Cannot read property 'sub' of undefined
TypeError: Cannot read property 'sub' of undefined"
error
@@johnchristianardosa3822 Try deleting the dist folder and running the app again
@@vladgoeswild That worked really well. Thank you! I just had another strange error in a different Nest app and that was also the problem there. Great video, thank you so much!
@@vladgoeswild I don't know why my previous comment didn't show.
Thanks a lot. Very nice 🔥🔥
Thank you. I have learned a lot.