How to Implement Refresh Token in ASP.NET Core Web API
Вставка
- Опубліковано 12 гру 2024
- ►► Check out our courses: bit.ly/cdmz-co...
►► Support us on Patreon and get the source code: / codemaze
In this video, we are going to learn about refresh tokens, their use in modern web application development, and how to implement this feature in the .NET Web API using the latest framework.
Refresh tokens are credentials that can be used to acquire new access tokens. When an access token expires, we can use a refresh token to get a new access token from the authentication component. The lifetime of a refresh token is usually set much longer compared to the lifetime of an access token.
LINKS MENTIONED IN THE VIDEO
►► Global Exception Handling: • Global Exception Handl...
FOLLOW US ON SOCIAL MEDIA!
►► / marinko-spasojevic
►► / codemazeblog
►► / codemazeblog
![ASP.Net Core Web API JWT Tutorial [Using JWT in ASP.Net Core]](http://i.ytimg.com/vi/w8I32UPEvj8/mqdefault.jpg)
Thank you all for watching and for your support.
►► If you want to check out all our courses you can do that here: courses.code-maze.com/courses/
You made refreshtoken implementation simpler. Thanks for sharing 😊
Glad it was helpful! Thank you for watching.
How to implement from client application like angular or MAUI
Just yesterday implement refresh token but a bit different, using cookies for refresh token.
Thx for video!
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.
Great! I Hope I Founded the right Tutorial & Channel
I hope so too! Thank you for watching the video.
Thanks first.
Excellent way of explaining
You are most welcome.
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?
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.
Why if token.expire
Ah sorry my bad.. im a bit sleepy and didnt read well 😅
So, you understand why?
@@CodeMazei missread it.. its if refreshtokenexpire
Ah ok. Makes sense. I thought you were talking about refresh token from begining :)
@@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
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.
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.
if someone gets hold of refresh token would they not able to use it to generate as many access tokens as they want?
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.
why are we encyrpting refresh token with RandomNumberGenerator Class can't we make that JWT too
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.
@@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
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.
@@CodeMaze Thank you !!😇
Thanks for the video. Appreciate
My pleasure! Thank you for watching.
can share with us this demo😇
Hi. We will soon provide the option for the source code.
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.
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.
@@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 ?
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.
@@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 ?
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.
Thank you
You're welcome. Thank you for watching.
Can you give a link to the source code?
Hi. We are working on it. Soon, you will be able to get the source code for all the videos.
Well, thank you.@@CodeMaze
Is there a link to the source code?
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.
Ok. No problem.@@CodeMaze
What if hacker gets both tokens
There is nothing much to say there - you have a serious security issue then. This simply shouldn't happen. But if you have a client app, and you store your tokens in some sort of storage, you can encrypt them in the client app first and then store them. That way, if someone steals them, the tokens will be of no value to them. Of course, you have to remember to decrypt them before using them in the request.