JWT - JSON Web Token Crash Course (NodeJS & Postgres)
ฝัง
- เผยแพร่เมื่อ 30 มิ.ย. 2024
- JSON Web Token (JWT, sometimes pronounced JOT) an internet standard for creating JSON-based access tokens that assert some number of claims. The tokens are signed either using a private secret or a public/private key.
In this video I want to discuss the difference between JWT (JSON web Tokens) and Session-Based Authentication. I will show examples with Node JS and Postgres. Finally, I’ll discuss the pros and cons of JWT.
Chapters
0:00 Intro
2:25 Session-Based Auth
9:00 JWT Based Auth
16:10 Refresh Tokens
25:17 Asymmetric JWT
28:16 Example coding
42:00 Pros and Cons
Slides can be downloaded here payhip.com/b/DPh3
SameSite • SameSite Cookie Attrib...
Source Code
github.com/hnasr/javascript_p...
Resources
philippederyck/st...
pragmaticwebsecurity.com/reco...
• Securing Stream Cipher...
• The Parts of JWT Secur...
draft-ietf-oauth-jwt-bcp-07 - JSON Web Token Best Current Practices
Follow Dr Philippe / philippederyck
🏭 Software Architecture Videos
• Software Architecture
💾 Database Engineering Videos
• Database Engineering
🛰 Network Engineering Videos
• Network Engineering
🏰 Load Balancing and Proxies Videos
• Proxies
🐘 Postgres Videos
• PostgresSQL
🚢Docker
• Docker
🧮 Programming Pattern Videos
• Programming Patterns
🛡 Web Security Videos
• Web Security
🦠 HTTP Videos
• HTTP
🐍 Python Videos
• Python by Example
🔆 Javascript Videos
• Javascript by Example
👾Discord Server / discord
Support me on PayPal
bit.ly/33ENps4
Become a Patreon
/ hnasr
Stay Awesome,
Hussein - วิทยาศาสตร์และเทคโนโลยี
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!
+1
I have watched plenty of jwt tuts and I can confidently say this is the best one on youtube. Great job!!
Also check out JavaBrains. That guy is the Jesus of explanations (assuming you believe in Jesus 😂).
Cleared difference between Session and JWT. Hope you make video on Kerberos.
Thanks,
Ratnadeep
+1 Kerberos
I must say Thank you so much Nazeer
really appreciate your work and efforts to educate fellow developers...
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!
Brilliant as usual !
Thanks Hussein !!, i voted for this !
got asked about it in an interview and answered pretty well based on what I learnt here. Thanks Hussein,.l
Thanks Hussein for the session, and please make a session on Kerberose
Don’t think you’re sly with those Count of Monte Cristo references. Great stuff.
Ado Sibalo nice ! Your the first to notice 👍
Beautifully explained the authentication mystery.
It was a mystery for me 2!
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
Vivek Dutta ❤️❤️ sending love to you and your brother and all my subs in India 🇮🇳
Nice topic and very good explanation as usual 😉.
Thanks Ahmed!!!
Many thanks for your videos!
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.
Observation: you would need to check redis on every request which will anyway add extra work, it would be the sames as just storing a cached session on redis, but with the extra complexity that jwt adds.
But nice idea anyway
Great video Hussein!
LawZist thanks Law 🙏
@@hnasr BTW how would you invalidate single user JWT token?
I know people use Redis for this kind of stuff. what is your opinion?
I talk about my thoughts on this at the end of the video. I would prefer asynchronous invalidation of jwt. Every x minutes the server query a DB to check if the token is still valid. I think its better than using a refresh token.
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.
The video is great. You could talk about OAuth too.
Well done.
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!
Mesmerizing ...!
This is so cooooool~
Thanks!
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.
I would love to see a video on kerberos
you are the best i love you
Thanks ;)
doing cse projects learning from this video. rip varsities.
love u
i vote for a kerberos video lecture : )
Interested to know about Kerberos, can you make a short video on this please?
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?
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 ?
that is exactly what I was thinking. Since you cant manually remove it from cookie, why wouldn't server just set-cookie as an empty string or some garbage invalid data
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.
Hi Hussein,
Why do you store refresh token in the local store ?
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 :)
This is a good way but depends on how long your access token lives because if it's like 30 mins and user have stored the token somewhere they can still make the request.
If you really have a very important things to do with JWT or probably it's required for your business to run than you can create the ideology of sessions around access tokens but if not I would say to go with sessions.
Using Web Sockets could avoid the latency for critical services since the JWT can be updated independent of the API request
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?
Hello Hussein .. Why does the refresh token validation need a separate decryption key from the actual token decryption key ?
Because sharing the same key is generally a bad idea. If the access token key has been compromised we don’t want the refresh token to also be compromised
How are you deploying this, through the vscode debugger? Trying to follow; I'm so used to creating my own build/deploy scripts 😩
hey hussain can you make a video on attacks like xss. It will be good to know practically how these atacks are done
Ditto on the refresh token :-)
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
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.
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
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?
Not really because the token has the expiry date. You can clear the tokens locally but If someone got the token they can still use it. That is why it is stateless.
it's not the user that's the problem it's the bad actors that may access user's access token
it still leaves the door open for bad actors to get it before user logs out if they can get it
For stolen refresh token, what about 1 to 1 mapping. so only one access token can be paired with a refresh token.
That's what called as Refresh Token Rotation
Hi Hussein,
i am interested to know kerberos.. can you make short videos ?
11:50 "symmetric key like RSA" - Shouldn't it be AES/DES/Twofish/Serpent instead of RSA?
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.
yatendra maurya two ways: the client can keep using the access token with their requests until the request fails .. and client captures that failure and regenerate the token by sending the refresh token.
Or a the client can set a timer to issue a generate a new token right before the token expires (since the client knows when the token will expire)
I think the idea of refresh token as I described in the video is a hassle on the client.. so I proposed another idea at the end of the videos (cons section)
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 ?
Oh this is in the html file in the jwt-final folder. Since it is Javascript code client side
Kerberos, please!
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?
That's why access tokens meant to be short lived.
I would always prefer to use Refresh tokens for very frontend connected services but if you are making some kind of lib for backends and authz is needed than I don't think refresh token is needed.
how I do migration database from type text to type long arcgis ?
Next vid idea 12 factor app
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?
Cesar P Hey Cesar, JWT is not better than session both has pros and cons ..
But yes the “best practice” for jwt is to make access tokens short-lived and when they expire or ( about to )the client is responsible to generating new access token using the refresh token. At the end of the video I give my take that I don’t like that approach and provide another option using what I called and asynchronous authentication.
For session auth we don’t have this problem you basically shouldn’t make your session short lived unless you want the user to be forced to login after x period of inactivity (banking systems ) do that..
@@hnasr maybe another way to get this refresh token working would be to send the shortlived token to the server and if it gets back and error (because expiration) then you request a new one with the refresh token.. that way you a new one on demand if you require to keep using the service (instead of hitting the server every x amoutn of time to keep the token 'alive')
Happy Ramadan
Abinash Ramadan Kareem!
want videos on kerberos, oauth and difference btwn oauth and federated login.
Hi Nasser,
What would happen if the Refresh token gets compromised ?
That's where we do something called Refresh Token Rotation.
Backend will regenerate the refresh token after every access token expiration and ask client to set it back.
Even if refresh token gets compromised after the expiration of access token refresh token will also not work.
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.
@@kronsyc339 Thanks for you reply. But i don't understand this line -- " then simply delete the row with the session " . If possible please explain.
@@kronsyc339 i am . Actually i wanted to know how would you suggest and why . Thanks
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.
Good point about using the creation time of the token to revoke those too. Never realized it. Thanks ;)
Are both access tokens and refresh tokens jwts?
They can be, but they don't have to be
so, essentially, we decreased frequency of the session db hops.
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.
Hey Sayed
How would you regenerate the token after it expires?
@@hnasr if the difference between now and the time issued is less than the specific time, then the controller would response as Unauthorised and the user will have to call the refresh controller API to get a new token.
@@hnasr it should expire after long time and for sure the user should have already renewed it before it get expired.
Wouldn’t that require a refresh token to hit the refresh api? Or at least credentials?
@@hnasr yes it will require if the user never called any API which require JWT authentication that depend on "time issued at" constraint for 7 days as an example or didn't explicitly renewed his token, then the user will have to reauthenticate to get new token.
What is your opinion?
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?
Great idea 💡 I would put that logic in the reverse proxy too
@@hnasr Thanks for your reply. That’s encouraging! This is what I’ll try then once I get around to implementing.
In the meantime I still have a lot of other backend stuff to learn and this channel is really helping!
That's very good idea for signing a token but it's little complex for a stateless system.
Kerberos
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.
There's a very important reason which is sending refresh tokens with all the requests (it increases the size of request) which is not needed and when it comes to XSS then go with Refresh Token Rotation.
kerberos
Kerberos Pls
I also believe the refresh token idea doesn't make sense
Kerboros
11:34 ... JWT is not encrypted, it is base64 encoded.
Daniel J correct thanks, I mention this later in the video. The signature of the JWT is encrypted not the JWT itself. Any mention of encryption is referred to the signature in this case
requests - dnsmasq video
Web worker please
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.
Palo || ill sure break them into highlights good idea
I think it unnecessary, he included Timestamp for us to scrub through section.
I want to add something about refresh token and access token, I recently watched a video from Ben Awad about storing JWTs (th-cam.com/video/iD49_NIQ-R4/w-d-xo.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
the audio is really bad
Kerberos
kerberos
Kerberos
Kerberos
Kerberos