How to Implement Refresh Token in ASP.NET Core Web API

[@CodeMaze]

Thank you all for watching and for your support. ►► If you want to master Web API development using best practices, check out our Web API book: bit.ly/3x75ZMM ►► Also, to build great full-stack apps with Blazor, check out our course: bit.ly/3Pw3Y33

[@I-PixALbI4-I]

Just yesterday implement refresh token but a bit different, using cookies for refresh token. Thx for video!

[@CodeMaze]

Thank you for watching. Yeah, it can be done that way as well. For Web APIs I usually lean a bit more to JWT comparing to server-side apps like Blazor Server or Razor Pages, where I would probably go with cookies as well.

[@ElohimCode]

You made refreshtoken implementation simpler. Thanks for sharing 😊

[@CodeMaze]

Glad it was helpful! Thank you for watching.

[@PowersoftIT]

How to implement from client application like angular or MAUI

[@Sharondevbd]

Great! I Hope I Founded the right Tutorial & Channel

[@CodeMaze]

I hope so too! Thank you for watching the video.

[@zameer.vighio]

Thanks first. Excellent way of explaining

[@CodeMaze]

You are most welcome.

[@tanoryjakaperdana1419]

Why if token.expire

[@tanoryjakaperdana1419]

Ah sorry my bad.. im a bit sleepy and didnt read well 😅

[@CodeMaze]

So, you understand why?

[@tanoryjakaperdana1419]

​@@CodeMazei missread it.. its if refreshtokenexpire

[@CodeMaze]

Ah ok. Makes sense. I thought you were talking about refresh token from begining :)

[@tanoryjakaperdana1419]

@@CodeMaze haha sorry.. im trying to use sigin with google button (not google auth) and then convert the credential from google to jwtauth.. thanks for the video

[@alexalexander3252]

Hello, great video. Thou I can not get the following. What is "principal.Identity.Name" construction in RefreshToken method? Where does this "identity" property comes from? As you did not populate this prop when creating GetClaimsPrincipalFromToken method. I have a NULL in this value.

[@CodeMaze]

Hi. It is the Name claim that you assign while creating the token. Identity represents a property from the ClaimsPrincipal class and that property gets the primary claims of the current principal.

[@LuckyBwaromalePaul]

Thanks for the video. Appreciate

[@CodeMaze]

My pleasure! Thank you for watching.

[@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?

[@CodeMaze]

Hi. I never worked with MAUI so I am not sure what is going on there, but usually, on the client app, you should have some sort of interceptor that will intercept the request and check the token you are sending with the request and if it is about to expire or expired, you can first send the request to the Token endpoint to refresh the token, and then attach that new token to the request. That's the case with JWT auth.

[@mohamedroshdy4916]

can share with us this demo😇

[@CodeMaze]

Hi. We will soon provide the option for the source code.

[@salihe1232]

why are we encyrpting refresh token with RandomNumberGenerator Class can't we make that JWT too

[@CodeMaze]

Hi. No, I am not encrypting a refresh token. I am using that mentioned class to generate one. Refresh token isn't the same as the access token, so you don't need another JWT. You don't need claims and other stuff JWT has inside.

[@salihe1232]

@@CodeMaze So i want to publish a api and every api developer is doing like this way.So you say it is secure to publish it like that we don't need to encrypt the refresh token

[@CodeMaze]

You can do it this way. If you have a client app that consumes your API and stores the tokens in local or session storage, you can encrypt the access token inside the client app first, and then store it in the storage. Of course, everytime you send that token with a request, you need to decript it first.

[@salihe1232]

@@CodeMaze Thank you !!😇

[@ahmedrizk106]

this approach does not support user logging from multiple clients since there is only one refresh token/user at a time then once the first client consume it the second client will log out the user.

[@CodeMaze]

You are correct, and you shouldn't support that as well as it can be resky and so many companies abandoned that approach. Now, if you have a single user, you should be logged in from a single client.

[@ahmedrizk106]

@@CodeMaze how can you abandon supporting multiple clients when most apps have a mobile app and a web app and the user can be logged in on both at the same time ?

[@CodeMaze]

No, those are not the same. Web app and the mobile app are not using the same method. If you are using a mobile phone to access the web app, than it is the same thing and it shouldn't be supported. But mobile apps are different things.

[@ahmedrizk106]

@@CodeMaze sorry I misspoke what I meant was a mobile app and a web app accessing the same apis or maybe you are logged in from your laptop and your pc at the same time which is a common scenario how can you solve this ?

[@CodeMaze]

I am not solving that. As I said, when you have an API and a usual SPA client that consumes that API, it is a security risk to allow a single user to be logged in from multiple browsers. Because of that, for me, it is the rule that the user can use only a single browser/tab and be logged in.

[@coder3123]

if someone gets hold of refresh token would they not able to use it to generate as many access tokens as they want?

[@CodeMaze]

Well, yes. But that's really dangerous case. Basically, look at it this way, if someone gets keys of your appartment, what you can do until you notice that. This is something we try to avoid by storing the refresh tokens safely in our client applications that uses the Web API. On the client you can encrypt it and store it so if by any chance someone gets it, it would be meaningless to them. But if someone can intercept your HTTP requests, than you have bigger issues. Also, refresh tokens are not only about security but also about better user experience so we need to look them that way as well.

[@weradsaoud2018]

Thank you

[@CodeMaze]

You're welcome. Thank you for watching.

[@Famouse]

Can you give a link to the source code?

[@CodeMaze]

Hi. We are working on it. Soon, you will be able to get the source code for all the videos.

[@Famouse]

Well, thank you.@@CodeMaze

[@Famouse]

Is there a link to the source code?

[@CodeMaze]

I am really sorry, but it will be soon an option for that as well. It is a bit harder as this is part of our book's source code and I have to divide it somehow to leave only the relevant parts there. It would be unfair for the people who purchased the book to share the source code of the entire project.

[@Famouse]

Ok. No problem.@@CodeMaze