ASP.NET and JWT Refresh Tokens

Your JSON Web Token has expired. Do you have t go to the effort of entering your name and password again? Not if you have a refresh token.
Source code available at: github.com/Jas...
Topics include:
- Trading off security and convenience
- Synchronizing servers with ClockSkew
- Distinguishing the authentication server and the data server
- Storing refresh tokens on the database
- Returning a new JWT in exchange for and expired JWT and a refresh token
- Revoking a refresh token

[@CodingTutorialsAreGo]

Do you use refresh tokens or just stick with JWTs? Let me know in the comments. Server code available at: github.com/JasperKent/WebApi-Authentication Remember to subscribe at kzbin.info/door/qWQzlUDdllnLmtgfSgYTCA And if you liked the video, click the 👍.

[@TrevorWinns]

Spent ages trying to find a decent video and glad I bumped into this one have subbed to your channel as well keep up the good work!

[@marceloleoncaceres6826]

Great video!, maybe it's the only one that uses Logging, which I think is very important. Thanks a lot.

[@georgehomorozeanu]

High quality content, as usual. Very appreciated! Many thanks.

[@ex1us]

Thankyou for the tutorial! This is really useful for me

[@tobiaszwojnar1465]

your videos are amazing, yet another time only after watching your video I truly get an understanding of how sth works

[@alisonhj]

Great content! Thanks for sharing this awesome tutorial!

[@10Totti]

Best tutorial!

[@pemifo260]

What a gentleman! Thank you for this beautiful video. Not only are your clothes beautiful, but your diction is also amazing!

[@CodingTutorialsAreGo]

Thank you! 😊

[@pemifo260]

​@@CodingTutorialsAreGo I have some questions. 1) If we are returning a jwt token containing any kind of Name from the login endpoint, why do we check it again in the Refresh section? 2) Or since we sent this token, can't we be sure that it will contain ClaimsIdentity anyway? Finally, I think it's wrong that we return ClaimsPrincipal directly. If the jwt token is faulty, we may receive a 500 error because it cannot be parsed. For this I think we need to return TokenValidationResult and check if it is IsValid or not. Thank you from now!

[@mostafaessam592]

Awesome video ❤

[@marcioalexandremarcondes557]

Very very nice!! Thank you so much!

[@Lashib]

I can't say thank you enough. You literally saved me. Thank you very much sir. I tried to watch so many tutorial but failed because they are not beginner friendly. But you explain everything from fundamental level so anyone could understand it. I have a one question. Why did you choses to use Authentication Handler instead of updating the Authentication State provider and using it for accessing the login state.

[@CodingTutorialsAreGo]

The AuthenticationStateProvider is a whole video in itself, so I thought this was a better way to focus on the refresh tokens.

[@Lashib]

@@CodingTutorialsAreGo Thanks. waiting for it

[@sadafziya5636]

awesome, thanks for this great video

[@johannes3980]

Great Video!

[@diegomelgar2696]

Hi Jasper, again thanks for a high quality content video!! I wonder, having the Clockskew within the gap of the Tiemespan defined in the validation parameters. Wouldn’t it be appropriate to make the refresh token endpoint protected with Authorize attribute and documenting that the refresh token endpoint must be called within X seconds/minutes of time span in order to generate a new JWT? So, instead of creating a logic for adding a column or attribute for Refresh Token in Users table, the clockskew is the key for refreshing a new JWT, thus the Authorize data annotation will do the work to validate the token. Thanks again for your videos, they are very helpful 💯

[@CodingTutorialsAreGo]

I've never seen that done. I'm not sure the idea of requiring the client to refresh within a time limit is a very good idea. It would require the client software to be running a timer, which obviously wouldn't work if the client shutdown (which also would lose tokens in session storage, but not local storage). Even if the client did stay up it would mean unnecessary transmission and refreshes of tokens, when the client code decided to update but the user didn't, which would be a potential security compromise.

[@diegomelgar2696]

@@CodingTutorialsAreGo the scenario I am talking is exactly that. In which, the client code will pop up a modal with a timer that tells the user “hey, you have X seconds/minutes left to stay up in the session. Would you like to extend your session?” And if the timer reaches to the 0 seconds, then it would automatically logs out the user. This leads me to a second question. How to invalidate the JWT when the user logs out and the JWT is still valid? The client might erase the token from cookie or local storage but as you mentioned it could be stolen for example, a man in the middle attack. Thanks Jasper!

[@CodingTutorialsAreGo]

@@diegomelgar2696 That's one of the key things about JWTs - they cannot be invalidated, whereas refresh tokens can. That's why we have JWTs with a short expiry and refresh tokens with a longer one. I say they cannot be invalidated. You could make it so that the server holds a list of invalid JWTs which it rejects if they are used, but that's not the intended approach.

[@diegomelgar2696]

@@CodingTutorialsAreGo nice, thank you for your time and explanation Jasper!!

[@wissambishouty1383]

Thank you for the fruitful tutorial but i have one question why i need to pass the expired access token and active refresh token to the refresh endpoint so why i just send the active refresh token and then i check the users table for the passed refresh token and also check for expiration?

[@CodingTutorialsAreGo]

It's just a bit safer. A hacker would have to have stolen both.

[@wissambishouty1383]

@@CodingTutorialsAreGo Thank you for your clarification.

[@Rohit-gq4pv]

Just a question, what if same user logged in two different devices? For example, a user logs in first device; it will update the RefreshToken column for that user in AspNetUsers table. On device 2 login, it will update the existing RefreshToken column value(it will replace the device 1 refresh token with device 2 refresh token) .So for device 1, how will refresh token work?

[@CodingTutorialsAreGo]

You would need to store multiple refresh tokens in the DB.

[@Rohit-gq4pv]

Thanks 👍

[@johannes3980]

I have a question. When I have a MAUI app as the client, for example, what is the best practice for the refresh flow to maintain a high user experience? Because when the access token is invalid, it would take six calls until I have the data if the token needs to be refreshed. So, should the token be refreshed in the background if it’s expired to maintain a high UX? Regards

[@jacksonjohn9769]

Just a question. when we are calling refresh endpoint, did we need to update the expiry time of the refresh token?

[@CodingTutorialsAreGo]

It's up to you. If you update it, it will be more convenient for the user, but slightly less secure.

[@christianrazvan]

What version of asp core is that?

[@CodingTutorialsAreGo]

7

[@christianrazvan]

Thank you!