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.
I have another question, if refresh tokens are just refreshed every time the jwt expires, then isn't it moot? or is it like an added layer of security?
or is it because let's say a user makes 5 requests in 5 mins which is the ttl of the jwt, but the refresh token is used once every 5 mins. I still fail to understand why we need to rotate (i assume you mean regenerate) the refresh token.
@@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?
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 Most modern web apps which are SPA's have separate infrastructure where you have a dedicated backend serving a REST API to be consumed by a frontend hosted on a different domain. This makes API requests to the server cross-origin. Using this architecture, when you set the cookies as same-site, does it prevent the frontend from accessing the tokens?? Currently, what I do is store the tokens in local storage and to prevent CSRF attacks I add a CSRF token generated by my django backend to the API request headers. Is this a safe approach??
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.
To understand why JWT is stateless, you must know the difference between a Session Based Authentication and a Token Based Authentication. JWT is used for the latter because the tokens are not saved in the session store.
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.
thanks, good explanation!
3:47 Shouldn't it be the secret + header + payload?
Grate explanation!
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.
I have another question, if refresh tokens are just refreshed every time the jwt expires, then isn't it moot? or is it like an added layer of security?
or is it because let's say a user makes 5 requests in 5 mins which is the ttl of the jwt, but the refresh token is used once every 5 mins. I still fail to understand why we need to rotate (i assume you mean regenerate) the refresh token.
Really nice explanation
super clear, thx ! :)
That was an awesome video. Thanks.
Glad you liked it!
@@codinglyio UR GNNA LIKE WHATS COMING U F....UCKTARD
Super clear and helpful. Thank you!
Subscribed!
finally. thanks
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 😅
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?
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 Most modern web apps which are SPA's have separate infrastructure where you have a dedicated backend serving a REST API to be consumed by a frontend hosted on a different domain. This makes API requests to the server cross-origin. Using this architecture, when you set the cookies as same-site, does it prevent the frontend from accessing the tokens??
Currently, what I do is store the tokens in local storage and to prevent CSRF attacks I add a CSRF token generated by my django backend to the API request headers. Is this a safe approach??
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.
To understand why JWT is stateless, you must know the difference between a Session Based Authentication and a Token Based Authentication. JWT is used for the latter because the tokens are not saved in the session store.
Superb explanation ...
really good explanation, valuable
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.
👊 "Promo sm"
Una Rapid
A very thorough, yet succint explaination of JWT. Thanks, Ariel.
{2024-04-21}