Thanks for the super clear explanation. I have question related to Refresh Tokens being stolen: 08:13 "The first time legit user uses the refresh token, that refresh token is not valid anymore." But here is a catch, WHAT IF the malicious user uses the refresh token to get a new pair of tokens before the legit user? That means, after some time when legit user tries to use refresh token, he will not be allowed to do so, BUT malicious user will have all the access. What do you think about that?
A refresh token should never be used twice if you are rotating. Knowing this, your system can invalidate all the tokens for the user if a refresh token is used twice. Additionally, it wasn't mentioned, but you should return the JWT's as Secure HttpOnly cookies whenever possible. Secure means it's only sent with HTTPS, and HttpOnly prevents scripts from accessing it. Also SameSite strict/lax can help against CSRF.
Security reasons behind token expiration and rotation are clear, but not their mitigation. If, has an attacker, I have access to both tokens, then I am on equal footing with the legit user who also has both tokens. I could be the one getting the new refresh token / auth token as part of my requests even, UNLESS there's something else that you've neglected to mention, like a tie-in to the user's IP / Mac Address / etc. Also, you keep saying that the token is stateless but don't explain WHAT IT MEANS. Stateless is an incredibly loaded term in IT. I understood what you meant through the given example, but you should definitely pay more attention to such details.
I have watched the video multiple times and Istill don't understand it completely How is the JWT stateless Please make a detailed video showing how the token is generated on server and how it goes to cleint and how does the whole process work
It's considered stateless because it carries all the information within itself. There's no need for a session store. Maybe a simpler term is self-sufficient.
I'm kinda lost with the refresh token thing, the refresh token lives in the database right? so it defeats the purpose of JWT which is being Stateless (not need to query the db for authorization) *in the scenario where you can't have cookies e.g. mobile or desktop apps
Yes the Refresh Token lives in a DB. The idea is that you use your JWT for most interactions, as it contains claims about the user. This way, the server does not need to interact with the database for every request. This helps deal with scale and prevent bottlenecks from an auth server. For mobile apps, no problem not to use cookies, but local storage. The reason we use cookies (same-site, HTTP secure) to store JWTs on browsers is due to CSRF attacks and malicious extensions. That's not the case with mobile apps where you own the app.
@@codinglyio for clarification, We basically have 2 tokens of which access token (short-lived and store within memory maybe using state manager on front end) refresh token(stored in cookie, only sent when refresh token) right?
Superb explanation ...
thanks, good explanation!
super clear, thx ! :)
That was an awesome video. Thanks.
Glad you liked it!
Subscribed!
Amazing production quality. May I ask how did you create the animated portions of the video like the text and everything?
Blood, sweat and tears, using Adobe AfterEffects. My first time using it and it was hard 😅
Thanks for the super clear explanation.
I have question related to Refresh Tokens being stolen: 08:13
"The first time legit user uses the refresh token, that refresh token is not valid anymore."
But here is a catch, WHAT IF the malicious user uses the refresh token to get a new pair of tokens before the legit user?
That means, after some time when legit user tries to use refresh token, he will not be allowed to do so, BUT malicious user will have all the access.
What do you think about that?
A refresh token should never be used twice if you are rotating. Knowing this, your system can invalidate all the tokens for the user if a refresh token is used twice.
Additionally, it wasn't mentioned, but you should return the JWT's as Secure HttpOnly cookies whenever possible. Secure means it's only sent with HTTPS, and HttpOnly prevents scripts from accessing it. Also SameSite strict/lax can help against CSRF.
Security reasons behind token expiration and rotation are clear, but not their mitigation. If, has an attacker, I have access to both tokens, then I am on equal footing with the legit user who also has both tokens. I could be the one getting the new refresh token / auth token as part of my requests even, UNLESS there's something else that you've neglected to mention, like a tie-in to the user's IP / Mac Address / etc.
Also, you keep saying that the token is stateless but don't explain WHAT IT MEANS. Stateless is an incredibly loaded term in IT. I understood what you meant through the given example, but you should definitely pay more attention to such details.
I have watched the video multiple times and Istill don't understand it completely
How is the JWT stateless
Please make a detailed video showing how the token is generated on server and how it goes to cleint and how does the whole process work
It's considered stateless because it carries all the information within itself. There's no need for a session store.
Maybe a simpler term is self-sufficient.
I'm kinda lost with the refresh token thing, the refresh token lives in the database right? so it defeats the purpose of JWT which is being Stateless (not need to query the db for authorization)
*in the scenario where you can't have cookies e.g. mobile or desktop apps
Yes the Refresh Token lives in a DB. The idea is that you use your JWT for most interactions, as it contains claims about the user. This way, the server does not need to interact with the database for every request. This helps deal with scale and prevent bottlenecks from an auth server.
For mobile apps, no problem not to use cookies, but local storage. The reason we use cookies (same-site, HTTP secure) to store JWTs on browsers is due to CSRF attacks and malicious extensions. That's not the case with mobile apps where you own the app.
Do I need to store Refresh token in user's cookies??
Secure HTTP only cookie + SameSite, to protect against CSRF attacks
@@codinglyio for clarification,
We basically have 2 tokens of which
access token (short-lived and store within memory maybe using state manager on front end)
refresh token(stored in cookie, only sent when refresh token)
right?
A very thorough, yet succint explaination of JWT. Thanks, Ariel.
{2024-04-21}
👊 "Promo sm"