found this channel little late, and now I know there are lots of things to learn in software engineering ( knowing only CRUD operation is not enough 😂)

Please do a video on OAuth 2 sometime!

I have watched plenty of jwt tuts and I can confidently say this is the best one on youtube. Great job!!

Great video.. very clean explanation and up to the point with clarifying pros and cons of each approach! thank you :)

Hussein! I gotta say you nailed this presentation! I have learned a lot! Thank you for making this video!

I must say Thank you so much Nazeer really appreciate your work and efforts to educate fellow developers...

Cleared difference between Session and JWT. Hope you make video on Kerberos. Thanks, Ratnadeep

got asked about it in an interview and answered pretty well based on what I learnt here. Thanks Hussein,.l

Don’t think you’re sly with those Count of Monte Cristo references. Great stuff.

Brilliant as usual !

Thanks Hussein !!, i voted for this !

Thanks Hussein for the session, and please make a session on Kerberose

Beautifully explained the authentication mystery.

Many thanks for your videos!

saw many jwt videos, this is the best and most detailed sir, highly appreciate your content, i even urged my brother whos a backend dev at walmart labs in india, he became a fan of yours haha

Nice topic and very good explanation as usual 😉.

The way we implemented the logout functionality is we put the JWT's which came in for logout to a key in redis with an array of JWT's. During the validation of JWT every time before the request, we see whether the JWT is present in that redis key. If it's present, then it means that has been already logged out and we handle the request accordingly. If we want to manually make a key invalid, we can add that JWT to that redis key.

Very informative video Hussein!! Well done! Now, I can safely say that I got the idea behind JWT, HUGE THANK YOU! Why did you store the refresh token in localStorage instead of sessionStorage? What are the benefits? How would you remove it from the client? Will it stay there forever? Also, what if the user does not do ANYTHING on the page, does not click, move the mouse, nothing... yet under the hood after every REFRESH_TIMEOUT seconds, the client has to send a new request to keep the session alive? Now, that's (potentially) more database queries than with a session-based approach.

This video is a great mix of theory and implementation. I’ve been struggle with learning auth with JWT and sessions for almost 2 months. And this video along with some other videos has made me go with sessions. After building a small app using just an access token, I wanted to improve and implement refresh tokens and silent refresh but I kept asking myself - why should I? 1) If JWT is suppose to be ‘stateless’ then why do I have to still persist data server side and store in DB or Redis? Like isn’t this just sessions but with unnecessary complexity? Lol 2) As I’m doing more and more research I see a lot of articles on why JWT isn’t all the way secure or how JWT is secure but ‘xyz’. On the other hand, I found nobody really has nothing bad to say about sessions other than it is the old way of doing things. However, imo that just tells me that it’s battle tested and solid. As for JWT there are a lot more concerns to consider than good ole sessions imo. All in all, there are pros and cons to both but for now I’ll just play it by project but will look to use session based auth first. Thank you for this video and much gratitude!

The video is great. You could talk about OAuth too.

About the JWT logout: I believe it's up to the system designers. If we simply keep the access token in the application code/session storage and attach it to each request, we can then remove it from those places when the logout button is being pressed and we won't experience such an desynchronization. Obviously, if a third party sniffs out our access token somewhere in between we have a problem, but this is a different issue I think.

Mesmerizing ...!

Well done.

Hi Hussein , One question .... Since JWT is anyway having the claims data as a part of the signature ( which is decrypted in the server ), why do we need to have it in the data section as well? Why not just take the claims data , encrypt it with the private key and send it? Is it coz frontend cannot decrypt JWT but can use it for UI rendering access control?

Thanks!

How are you deploying this, through the vscode debugger? Trying to follow; I'm so used to creating my own build/deploy scripts 😩

This is so cooooool~

Hi Hussein, Why do you store refresh token in the local store ?

great video.. 🙏 My questions: 1. When we are going to store Refresh tokens in DB, why do we need to make them JWT tokens at all? why cant plain old GUIDs work as refresh tokens, as they used to, in case of session IDs 2. Is Logout completely a Client Side gimmick in this design?

you’ve probably figured this out by now (or some other comment may have mentioned it) but when user hits that logout button, just do a BEAUTIFUL redirect on the server. thus, eliminating that requirement to manually refresh the page aka BEAUTIFUL F5.

how I do migration database from type text to type long arcgis ?

Great video Hussein!

doing cse projects learning from this video. rip varsities.

Thanks ;)

I would love to see a video on kerberos

you are the best i love you

11:50 "symmetric key like RSA" - Shouldn't it be AES/DES/Twofish/Serpent instead of RSA?

Hello Hussein .. Why does the refresh token validation need a separate decryption key from the actual token decryption key ?

i vote for a kerberos video lecture : )

To logout immediately, I first set the refresh token to null in database and I set the value of access token (JWT_TOKEN in your case) in cookie to empty or null from backend as res.cookie("key","", maxAge: 1 }); and redirect to other page If there is a better way please tell :)

It is great to watch your videos Thank you. Just one question, for logout if we spin up an endpoint and if it set a cooke, set-cookie with a random jwt token (token like) then it should fail for the next request right ? my understanding is wrong or any potential problem with that ?

Its so frustrating spending literal days trying to find decent examples of using JWT and not find anything great, and then finding out that a person I'm subscribed to had one this whole time... I hate youtubes algorithm. Are you still considering making and example?

You can avoid XSS and CSRF by storing the jwt in a secure, http only, same site cookie. i really don't see any point of using refresh token it's just putting more complexte on both client and server

Interested to know about Kerberos, can you make a short video on this please?

love u

Using Web Sockets could avoid the latency for critical services since the JWT can be updated independent of the API request

Hi Nasser i have gone through your code but couldn't get the code which is initiating the /token request. I mean you had logic for refreshing the token in this /token post request but how is this getting called ?

How does client knows that its Tokes is expired and he needs to send the refresh token. Or Client sent refresh token every time and server generates the new token if previous is expired validating its refresh token.

The issue with using access token directly without refresh token is if you share it with other party they can get new token again.. I think that is the reason for using refresh token separately and you won't share the refresh token with any third party.

For not using refresh token mentioned in the Cons section, how would you ascertain that access token is stolen, isn't that very difficult? I mean you can run heuristics to check invalid IPs/Bots but still attackers can mimic IPs to be valid no?

Hi Nasser, What would happen if the Refresh token gets compromised ?

Thanks for the great video Hussein I just have a question: When using a refresh token, you say there's no way to logout from a website even though the refresh token has been deleted from the backend database. I under this is because the access token has not yet expired. But can't you add a few lines on the client side that clear any stored access token (expired or not) when the user clicks logout? Of course, this doesn't make the access token invalid, but from the user's perspective, they're logged out and they no longer have access to any token. Am I understanding this correctly or am I totally missing the point?

hey hussain can you make a video on attacks like xss. It will be good to know practically how these atacks are done

For stolen refresh token, what about 1 to 1 mapping. so only one access token can be paired with a refresh token.

Ehhh... I mean I've never used JWT so clearly my opinion of it is coloured by that, but it just seems so superfluous. First off, the concepts of J (and arguably W) are completely irrelevant, it's a signed token, and that's it. Secondly, if you want your servers to be able to avoid hitting the databases sometimes, cache locally. Have your HAProxy in layer 7 mode, and stick clients based on the session ID cookie, and then the servers can then happily cache the rows from the session ID, and do a fetch every so often to invalidate. The fetch can even be asynchronous, or even event driven. Have the database publish to an event stream when a session row is deleted, and have the servers subscribe to that. Every few minutes (or on the events if needed), the servers tell their local redis `DEL session_data_`. The only problem that could throw up is if the user somehow logs out on a different instance to what they've been stuck, and then manage to not delete their cookie as instructed, AND then provide it back to the original server that hasn't noticed they've been logged out yet, and even then all that means is they're a different user for a little bit. Reaching for asymmetric encryption to have the users hold some data to save the servers executing a SQL query sounds a hell of a lot like job security in action, same as GraphQL. --- E: Absolutely fantastic explanation and presentation thereof by the way. I dislike the thing you described, not your description of it.

Thanks for your efforts. But i didnt find any use of refresh token. We can also achieve same functionality using only access token. Plz see below flow without refresh token 1. Login Endpoint - Generate access token with expiry 15 minute & save it to DB against corresponding user. 2. Protected Endpoint - verify access token. If expired, return message "token expired" . 3. Refresh Endpoint - Verify & regenerate access token only if it is expired & exist in DB. Replace old access token in DB with new one. Please solve my doubts. Thanks

Ditto on the refresh token :-)

did you say that to keep you session alive you have to keep generating a new token every 30 seconds (or any random xx time ) with your refreshtoken so it keeps 'alive'? how is this better than just not just validating your session at the server (old fashion) only when you ask for it instead of taxing the server so many times to refresh the cookie jwt and keep alive?

Kerberos, please!

Hi Hussein, i am interested to know kerberos.. can you make short videos ?

Are both access tokens and refresh tokens jwts?

want videos on kerberos, oauth and difference btwn oauth and federated login.

Happy Ramadan

Next vid idea 12 factor app

This was really great. Actually I m currently working on a project which have a requirement like blacklist user.So super admin can blacklist a user and when he do that, that user can not log in to the application any more. And it's clear that I can't expire a jwt token forcefully. So what I did was, I stored those token which was blacklisted by admin in a separate table called blacklist_user. And for every request I m checking that particular token is available or not in blacklist table. And based on the result returend by the query, I am sending the response to the user . If token is available in blacklist table that means user can't log in. so i want to know what could be the best approach in this case? Thanks is advance.

8:50 Pretty certain you hate the topic, but cache invalidation might be a good topic for a video ? :-) 10:22 You know it reminds me of TLS stateless session resumption (session tickets), the original RFC is from 2006 28:18 your voice changed ? 47:19 public keys can be stored with the code 51:32 refresh token isn't a con, other than 'very tricky to consume correctly', because it's just as safe as a long-lived session cookie (people used to set cookies valid). 53:19 yep, the revocation list is going to be _very_ small, assuming it has a limited lifetime like 24 hours, dump it in a small Redis running on each webserver or something like that. Because how often does someone call you and tell you some credentials were stolen ? Also session tokens can have a creation time and anything created before the revocation can just be seen as invalid too. So it's not valid for those 15 minutes either.

so, essentially, we decreased frequency of the session db hops.

Kerberos

Thanks for the video! Very clear explanation. In order to avoid needing added state and complexity with refresh tokens, would it be possible to instead harden the JWT tokens by signing them not only against the payload but also the incoming IP? (not part of the plaintext payload but derived from the HTTP packet or maybe on the TCP level?) Can you reliably get a client’s ip in node? Or better yet the MAC address? Is any of this realistic?

Hi Hussein I came with an idea in my application, instead of having two tokens then I can have one token which expire every 7 days with issued-at payload. Then in each microervice and depend on the severity of the data senstivity, the authentication will be approved only if the difference between now and token issued at < specific time.

Kerberos Pls

I want to add something about refresh token and access token, I recently watched a video from Ben Awad about storing JWTs (kzfaq.info/get/bejne/n6pkbMJ_rreRgmg.html) and in his video he talked about storing the refresh token in a cookie (HttpOnly) to prevent XSS attack and a comment in that video mentioned about limiting the scope of that cookie to only the authentication server to prevent sending the refresh token for every API request and CSRF seems to be useless since the token is only to refresh the access token and as for the access token it only gets stored 'in-memory' or in a JavaScript variable as Ben Awad said to prevent both XSS and CSRF. I'm curious what are your thoughts about this approach in storing JWTs

Great video, but certainly not a good idea to store refresh token in local storage, http-only, strict same site and secure is the way to go.

Kerboros

Web worker please

kerberos

I also believe the refresh token idea doesn't make sense

11:34 ... JWT is not encrypted, it is base64 encoded.

requests - dnsmasq video

I think you should split these longer videos into multiple videos. It's hard to sit down and watch an hour of content and I don't usually return to a long video even though I want to finish watching it. Tutorials that are split into multiple parts make them easier to finish.

the audio is really bad

Kerberos

kerberos

Kerberos

Kerberos

Kerberos