Brad comes along to save the day once again. Honestly bro I don't know how you do it.. 5 days of pain, dozens of videos and dozens of blog posts with unclear non-relevant over engineered information, then you come along and in one fell swoop answer EVERY SINGLE QUESTION I had around the topic in a clear, detailed and swift manner. Thank you brother once again...
You're a role model to us all. I plan to improve my Patreon participation this coming year. I've grown in confidence as a software dev and have a job now thanks to your videos. Overall my life has seen a lot of improvement as a result of this channel, So thank you and Merry Christmas, Brad.
I needed a refresh about JWT functionalities and this little course was very helpful. Just one mention. Token name that we send with res.header can be anything for example 'auth-token', not just 'Authorizatiion'. And token value in a name-value pair doesn't have to start with 'Bearer' word, it's enough to send token only. In that case we do not have to split result into name 'Bearer' and token value.
Thank you so much! I’ve been struggling trying to make a protected route with passport for the past month. I couldn’t get it working on a side project I was working on would get super frustrated. I watched this video last night and was able to get it working today! You are a God send! 🙏🏽
Reaaaaaly liked the straightforwardness of the tutorial. Implemented it on an existing server in under 40min thanks to your tutorial, keep up the good work :D
5 лет назад+1
I came from the MERN series part 9 to learn more about JWT before implement it to the project. And I made it even it is my first time using auth. Thanks, Brad. 👏🏽 Excellent content as always!!
Don't dislike knowledge. Knowledge can be appreciate only. It's not a movie which can be like/dislike. Humble request to the people. Brad I really appreciate your knowledge which improve my understanding and skills. Thank you Brad for this fantastic tut.
Brad, your videos are amazing. Whenever I need to cut through the b.s. and learn something quickly, I come to your channel. This video is an enormous help to me. Thanks!
That also gives the nice advantage that the token itself doesn't get passed on the request object twice (req.token = bearerToken is no longer required). May not seem like much, but if you ever need to scale an application, even a few bytes of data per request can save a lot in the long run.
Merry Christmas Brad. I wanted this video badly. I was stuck with server side route authentication. Thanks for it and keep the good work going 😊. If possible please make a video using front end application, so that we will get more clear cut idea on this.
Merry Christmas to you and your family. You have been a big help and inspiration over the last year. I appreciate you and the extreme effort you put into helping people to learn. As always keep broadcasting!!
17:57 Beware: do not store JWTs in LocalStorage. Use an http-only cookie instead. Any javascript has access to locastorage, therefore by using it as your secure storage you lay your app open to xss attacks.
you shouldn't store the jwt in local storage, as it opens an attack vector for xss. an httponly cookie is the preferred way. now, it means that your rest api no longer is stateless, but it sure makes it way more secure.
Those who wants to know, what next() function is? i.e. In verifyToken(req, res, next). verifyToken is a middleware function in express, which take req, res and next parameters. Calling next will move to succeeding middleware function. More details here: expressjs.com/en/guide/writing-middleware.html
There are different types of Authorization, such as Basic, Bearer, Digest, HOBA, OAuth - even Amazon Web Services has one called AWS4-HMAC-SHA256. The idea behind it is allowing multiple ways of authenticating with the same API, or server. This dates back to the HTTP/1.0 standard from W3C :)
Awesome tutorial. Thanks for the time and effort put into this. I would rather rename that verifyToken middleware to something else like getToken to better capture what the middleware does.
One suggestion: Wouldn't it be more convenient to verify the jwt in the middleware and then attach the authData to the req object? This way you wouldn't have to verify the token in every route that you define. :) Otherwise, as usual, awesome tutorial, have a great great holiday!
Hi Brad, cool video and thanks, i needed a refresh! i think only that should be better to handle the verify in the middleware to keep the api clean, but great! thanks.
The way you did things makes little sense, you should have put the jwt.verify() function in the verifyToken() function and then set req.user equal to the return of that, that would make much more sense in the long run and would keep you from rewriting this for every endpoint. Also why use 'bearer ' as the auth header and not just set it to auth: ?
Hi Brad so I came accross and article that said storing JWT tokens in localstorage is a terrible Idea... since it is sensitive data and I'm thinking of incorporating it in my react ecommerce app I'm building... I just want to know how you feel about that point? Thanks in advance for your kind response
Clement Osuide I’m not Brad or a Software Dev, just a CS student. However, JWT tokens are unintelligible without the secret key that should only exist on the server side. And you should always implement a method to refresh tokens after they have expired at which point you are doing another check. That part wasn’t really covered in this video though. Anyway, storing you token on the client side for the duration of the session should be fine. I’m not sure if there is some issue specifically with localStorage vulnerabilities though. I’m also aware one of the benefits of JWT is unlike standard sessions there isn’t any need to store the JWT on the server usually you would save session information. There is a great explanation by Web Dev Simplified that goes into explanation of everything about JWT vs regular sessions and he has a separate implementation video that goes into implementing a refresh token if you’re curious. I’m sure with Brad being a web developer he could probably give you a more relevant and specific answer than I could. Hopefully, that’s something for the time being though. Edit: You can encrypt JWT tokens with JWE though it sort of defeats the purpose of having them. JWT is in fact not encrypted by default and is only base64url encoded. So, is pretty simply to decode. Therefore, as you mentioned a big problem is going to be XSS attacks when you store the JWT on the client side. Therefore, essential user information shouldn't be within the JWT payload and other methods should be used to handle XSS through JWT. When using JWT there is no workaround and the client must have the JWT stored on their side to allow the server to verify the client request, which means it's open for XSS attacks eherther you choose localStorage, sessionStorage, and so on.. Generally, JWT is really good for integrating with native mobile apps (nothing needs to change on the server) and it is easily scalable because unlike sessions tokens aren't stored on the server and to add a server one only needs to include the secret key. In conclusion, unless you are well-versed in creating XSS protection or want to go through the research process of adding other authentication methods to secure your web app I would not recommenced JWT. It is unlikely you will need to scale your personal app to multiple servers and even in that event it probably won't be more than a few. So, one of the primary benefits of JWT is lost for a smaller-scale personal web app. Implementing JWT for demonstration purposes is always fine though. But, for smaller-scale personal web apps session based authentication is probably the way to go. Since, the user isn't stored in the paylaod XSS attacks isn't much of an issue and while CSRF attacks are opened there are widely available methods of dealing with that.
"you shouldn't store the jwt in local storage, as it opens an attack vector for xss. an httponly cookie is the preferred way. now, it means that your rest api no longer is stateless, but it sure makes it way more secure." -another comment made by someone else
Thank you Patreon patron for this request and thank you Brad for the tut!
You're very welcome. Great channel by the way, guys check it out
Brad comes along to save the day once again. Honestly bro I don't know how you do it.. 5 days of pain, dozens of videos and dozens of blog posts with unclear non-relevant over engineered information, then you come along and in one fell swoop answer EVERY SINGLE QUESTION I had around the topic in a clear, detailed and swift manner. Thank you brother once again...
You are not the only one who makes video about JWT, however, you deliver the knowledge in clearest and easiest way. Thank you Brad!
In 2020, with v12.15.0 everything still works exactly the same, I just run through your tutorial. Thank you Brad!
That's good, because I'm going to do this tutorial soon.
One of the shortest, yet most succinct, useful tutorials I've seen. Brad rocks!
You're a role model to us all. I plan to improve my Patreon participation this coming year. I've grown in confidence as a software dev and have a job now thanks to your videos. Overall my life has seen a lot of improvement as a result of this channel, So thank you and Merry Christmas, Brad.
Thank you, Merry Christmas to you as well :)
Great to hear buddy, hope you're still doin' well :)
I was literally just looking up how to do this and this video pops up. This video is a God send lol. Perfect timing.
I needed a refresh about JWT functionalities and this little course was very helpful. Just one mention. Token name that we send with res.header can be anything for example 'auth-token', not just 'Authorizatiion'. And token value in a name-value pair doesn't have to start with 'Bearer' word, it's enough to send token only. In that case we do not have to split result into name 'Bearer' and token value.
I always struggle understanding the auth stuff but you have managed to explain it so well. Thank you so much for this tutorial Brad!
Thank you so much! I’ve been struggling trying to make a protected route with passport for the past month. I couldn’t get it working on a side project I was working on would get super frustrated. I watched this video last night and was able to get it working today! You are a God send! 🙏🏽
Reaaaaaly liked the straightforwardness of the tutorial. Implemented it on an existing server in under 40min thanks to your tutorial, keep up the good work :D
I came from the MERN series part 9 to learn more about JWT before implement it to the project. And I made it even it is my first time using auth. Thanks, Brad. 👏🏽 Excellent content as always!!
Man I love this tutorial... Other RUclipsrs take more than 1 hr to explain just this. But you did it in less than 25 mins..
Don't dislike knowledge. Knowledge can be appreciate only. It's not a movie which can be like/dislike. Humble request to the people. Brad I really appreciate your knowledge which improve my understanding and skills. Thank you Brad for this fantastic tut.
This is an excellent, no-nonsense, straight-forward explanation of using JWTs to protect API routes, thanks.
This is exactly what I needed. Short, sweet, and to the point! Have a great holiday, man!
Brad, your videos are amazing. Whenever I need to cut through the b.s. and learn something quickly, I come to your channel. This video is an enormous help to me. Thanks!
Brad Bhai (brother in India), thanks a lot for the succinct explanation..always love the explanation in code.
Clear & to the point without irrelevant information.
Thanks Brad you've been helping me so much for almost a year.
Cheers 🍻
Probably the best JWT tutorial on the internet.
You could have handled the JWT verification in the middleware, to keep responsibilities nicely separated. Other than that, nice tutorial :)
That also gives the nice advantage that the token itself doesn't get passed on the request object twice (req.token = bearerToken is no longer required).
May not seem like much, but if you ever need to scale an application, even a few bytes of data per request can save a lot in the long run.
Yes.
The authentication should be done at the middleware.
What Brad did works better for authorization once in the route handle.
Merry Christmas Brad. I wanted this video badly. I was stuck with server side route authentication. Thanks for it and keep the good work going 😊. If possible please make a video using front end application, so that we will get more clear cut idea on this.
yes please, agreed !
This is the course I've been looking for! Brad, you are the best!!
Merry Christmas to you and your family. You have been a big help and inspiration over the last year. I appreciate you and the extreme effort you put into helping people to learn. As always keep broadcasting!!
This is exactly what I was looking for !
Now I know how to make it work. Clear and simple.
thanks its really helpful video, my boss was struggling with this authentication for a very long time, but now we will prove that who is the boss
17:57 Beware: do not store JWTs in LocalStorage. Use an http-only cookie instead. Any javascript has access to locastorage, therefore by using it as your secure storage you lay your app open to xss attacks.
Well, localStorage is generally the preffered method. Moreover cookies are not any safer, they are prone to CSRF attacks as well
@@TheAndre2131 Yep, that's why we invented CSRF tokens!
I have been waiting for this Brad, I can't thank you enough
october 2021 still works!
thx brad
I have seen two of your videos and found this channel very helpful. Thank u :)
Awesome! I wish each my question on the Internet had such a clear explanation
The verifyToken middleware should do the token validation and, in case of, check the token is valid from the DB.
You have some of the best web tutorials I've found yet. I bought also your Udemy MERN stack course, can highly recommend! Thanks.
I implemented this 100% successfully. Thanks, Brad.
you shouldn't store the jwt in local storage, as it opens an attack vector for xss. an httponly cookie is the preferred way. now, it means that your rest api no longer is stateless, but it sure makes it way more secure.
Best technical videos on youtube, keep up the good work!
Doing the lords work. Thanks a bunch, this just helped me through the toughest part of my current project.
Very useful even after 3 years! Thank you Brad!
I am a huge fan of your tutorials, thank you so much for all these great videos
Thanks for recording this video. Things are a lot clearer now.
Simple, To the point and concrete. Thanks Buddy!
That was a huge amount of help , really easy to understand and you explained it in a calm , quite and nice manner which is really important
This video was very well done, very informative, and exactly what I was looking for.
Thank you, I learned much more than I bargained for.
Best video on node and jwt so far. Thanks a lot.
Thank you brad for this awseome tutorial , just a note we should send only the id in the payload as far as read in articles
Those who wants to know, what next() function is? i.e. In verifyToken(req, res, next).
verifyToken is a middleware function in express, which take req, res and next parameters.
Calling next will move to succeeding middleware function.
More details here: expressjs.com/en/guide/writing-middleware.html
Thank you, i learned how to use a token to access protected routes. LOVE IT MAN!
I found this video at the right time, thanks Brad
Excellent video. Short and to the point. Thank you for not building a client and using PostMan instead.
I love watching your tutorials and this is brilliant. Many thanks!
Well, this is one of the breakthrough demos of oauth present in youtube. Great job man.
Why do we need the Bearer string in the authorization? instead of header['authorization'] = '' ?
There are different types of Authorization, such as Basic, Bearer, Digest, HOBA, OAuth - even Amazon Web Services has one called AWS4-HMAC-SHA256. The idea behind it is allowing multiple ways of authenticating with the same API, or server. This dates back to the HTTP/1.0 standard from W3C :)
now i understand jwt and how to use it... thanks Brad!
This is exactly what i needed, amazing stuff!!!
Thanks Brad , I hope that you do a full mean stack project
5 years later…. Still gold
Thank you so much for your tutorials. They are very informative. You are an inspiration to us all. Could you do a refresher for the PostresSQL tut?
Thanks for the video, clear and easy to understand!
Awesome tutorial. Thanks for the time and effort put into this. I would rather rename that verifyToken middleware to something else like getToken to better capture what the middleware does.
Agree. Was about to comment this.
May be a good idea to state that this should be done over https, though most people should already know this.
One suggestion: Wouldn't it be more convenient to verify the jwt in the middleware and then attach the authData to the req object? This way you wouldn't have to verify the token in every route that you define. :)
Otherwise, as usual, awesome tutorial, have a great great holiday!
left as an exercise to the viewer ;)
thanks traversy, such a legend for me and an inspiration...
This is exactly what i was looking for!
A very nice tutorial sir , you r a role model for all of us , thank you sir !!
Thanks Brad, great video, happy holidays.
Wonderful tutorial. Please make a tutorial on Node+Express+Angular+JWT+Socket
Sir really awesome video. Made me understand completely about jwt
I love you. Thanks so much for the video. Crystal Clear in all aspects and I got the exact and even more information I needed.
Very nice explanation with working code examples
Thank you for this! I can expand upon this and save a good few lines of code and a dependency with it.
Very informative and easy to follow. Thanks!
In a lot of videos I see req.headers["authorization"], but why not just type req.headers.authorization?
Thank you SO MUCH for your lesson. It really helped me a lot!!!
Awesome stuff brad as always!
Make things pretty clear. Simple and Clean. Thanks.
does it will be better to move "jwt.verify(....)" to the middleware function ???
Congrats 🎊 Brad for 500k subscribers ✌️👍👏🎈🎁💐
Thank you from Italy, very clear and helpful!
Woww this cleared my all the doubts. Thank you so much ❤
Very clear explanation. Thanks Brad.
Your explanation was perfect. Thank you so much!!
You have my like and my sub :)
Great tutorial, clear & simple to follow!
Hi Brad, cool video and thanks, i needed a refresh! i think only that should be better to handle the verify in the middleware to keep the api clean, but great! thanks.
Great video but for who already know why jwt is needed and has theoretical knowledge of token👍❤️👌🥳
very good, simple and clear tutorial
The way you did things makes little sense, you should have put the jwt.verify() function in the verifyToken() function and then set req.user equal to the return of that, that would make much more sense in the long run and would keep you from rewriting this for every endpoint. Also why use 'bearer ' as the auth header and not just set it to auth: ?
tools.ietf.org/html/rfc6750
you saved my day ! again!
thank you brad!
Really great explanation sir... Simple and worthy ...
14:04 you could also do: const [,bearerToken] = bearerHeader.split(' ');
Perfect! Thank you, Brad! My hero!
Great work helping the community in a short video with excellent and straight forward professional explanation.
This turorial was help me solve my problem. Thanks!
This video is open path for me to develop custom token in firebase database
Perfect video as always. short and useful.
Hi Brad
so I came accross and article that said storing JWT tokens in localstorage is a terrible Idea... since it is sensitive data
and I'm thinking of incorporating it in my react ecommerce app I'm building...
I just want to know how you feel about that point?
Thanks in advance for your kind response
Clement Osuide I’m not Brad or a Software Dev, just a CS student. However, JWT tokens are unintelligible without the secret key that should only exist on the server side. And you should always implement a method to refresh tokens after they have expired at which point you are doing another check. That part wasn’t really covered in this video though.
Anyway, storing you token on the client side for the duration of the session should be fine. I’m not sure if there is some issue specifically with localStorage vulnerabilities though.
I’m also aware one of the benefits of JWT is unlike standard sessions there isn’t any need to store the JWT on the server usually you would save session information.
There is a great explanation by Web Dev Simplified that goes into explanation of everything about JWT vs regular sessions and he has a separate implementation video that goes into implementing a refresh token if you’re curious.
I’m sure with Brad being a web developer he could probably give you a more relevant and specific answer than I could. Hopefully, that’s something for the time being though.
Edit: You can encrypt JWT tokens with JWE though it sort of defeats the purpose of having them. JWT is in fact not encrypted by default and is only base64url encoded. So, is pretty simply to decode. Therefore, as you mentioned a big problem is going to be XSS attacks when you store the JWT on the client side. Therefore, essential user information shouldn't be within the JWT payload and other methods should be used to handle XSS through JWT.
When using JWT there is no workaround and the client must have the JWT stored on their side to allow the server to verify the client request, which means it's open for XSS attacks eherther you choose localStorage, sessionStorage, and so on..
Generally, JWT is really good for integrating with native mobile apps (nothing needs to change on the server) and it is easily scalable because unlike sessions tokens aren't stored on the server and to add a server one only needs to include the secret key.
In conclusion, unless you are well-versed in creating XSS protection or want to go through the research process of adding other authentication methods to secure your web app I would not recommenced JWT. It is unlikely you will need to scale your personal app to multiple servers and even in that event it probably won't be more than a few. So, one of the primary benefits of JWT is lost for a smaller-scale personal web app. Implementing JWT for demonstration purposes is always fine though. But, for smaller-scale personal web apps session based authentication is probably the way to go. Since, the user isn't stored in the paylaod XSS attacks isn't much of an issue and while CSRF attacks are opened there are widely available methods of dealing with that.
"you shouldn't store the jwt in local storage, as it opens an attack vector for xss. an httponly cookie is the preferred way. now, it means that your rest api no longer is stateless, but it sure makes it way more secure." -another comment made by someone else
Very well explained . Thanks so much for this video
Again, you're amazing.
Thank you so much..
So clear and lucid explanation
Crystal Clear even in 2022
Hi Brad Sir, I love the way u xplain...
U xplain the things in a simple way...
Thanks...Only way I know how :)