Give more info about RefreshToken

[giuseppe-terrasi]

This page explains clearly how to retrieve the AccessToken and the RefrehToken from OpenId authentication and how to use the AccessToken. But, it doesn't explain how to use the RefreshToken and, more important, how to persist the new received tokens across multiple circuits.

OpenId uses cookie authentication but a cookie cannot be directly updated from a Blazor component or from a ServerAuthenticationStateProvider so what is the best practice to handle token expiration?

Thanks

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 6f8acbbf-c9d4-7041-c1a7-ec9ce8f0981b
• Version Independent ID: c98be365-408d-7ee6-cb74-14c44d01b0b8
• Content: ASP.NET Core Blazor Server additional security scenarios
• Content Source: aspnetcore/blazor/security/server/additional-scenarios.md
• Product: aspnet-core
• Technology: aspnetcore-security
• GitHub Login: @guardrex
• Microsoft Alias: riande

[guardrex]

Hello @giuseppe-terrasi ...

... it doesn't explain how to use the RefreshToken and, more important, how to persist the new received tokens across multiple circuits.

Yes, that's correct for the coverage on performing any action in Razor components with a refresh token (and in the context of multiple circuits).

... what is the best practice to handle token expiration?

Thus far, the lack of recommendations, best practices, and examples for using the RefreshToken is by design.

Developers have asked about token management and user flows for expired tokens on the product unit's repo. For example, here are a couple of issues in that vein ...

• AuthorizationMessageHandler fails to set authenticationstate on error aspnetcore#30927
• How to refresh my authentication cookie without redirecting to cshtml page in Blazor Server application aspnetcore#29819

... and there are likely other issues where devs ask about token management. I only performed a quick-'n-dirty search and grabbed a couple of issues that looked interesting. Try searching all of their issues (open and closed) with some "token" search terms (e.g., "refresh token"/"refreshtoken") and also search with the Blazor label (label:area-blazor).

This is a good time to re-ask the product unit if they'd like to provide more guidance in the doc. I asked years ago, but we didn't add guidance at that time, and I don't recall the reason that they gave me for avoiding further detail.

Leave this issue open, and I'll ping for triage on Friday this week. I don't know how fast you'll get an answer here. I hope you find some juicy tidbits and tips just by searching and reading the existing issues on their repo. That might at least tide you over until they address this issue here on the docs repo.

Two other avenues that you can pursue ...

• Search the Net for blogs and external articles on the subject.
• Search for existing convos (or packages that help with this) and/or inquire with devs on pubic support forums. We recommend the usual spots ...
  • Stack Overflow (tag: blazor)
  • ASP.NET Core Slack Team
  • Blazor Gitter
  • Awesome Blazor (Community-maintained collection of Blazor resources)

Eventually, we'll receive a response here. Stand-by! ... and thanks for asking about this.

[giuseppe-terrasi]

Hello @guardrex
thank you for your reply. I appreciate that this problem will be analyzed and I hope a common solution will be found. More support for updating client-side data from server-side code will be also useful.
Meanwhile, I've implemented a revalidation system that involves cookies, secured localstorage and events but I think that it is complicated and difficult to embed in a library.

[guardrex]

UPDATE (6/25): I've reached out to management again, and we'll base any coverage updates on whatever they say. I think that they're going to say that this is an advanced subject with many permutations such that we won't offer much explicit coverage. IIRC, Javier said to either allow the Blazor framework to automatically redirect to the ASP.NET Core part of the app for reauthenticating the user and/or to try-catch a failed access token request and manually redirect to the ASP.NET Core part of the app for re-auth ... AND that any user state must be preserved by dev code when these redirects take place or else the state is lost. We'll hear back on what should be added/updated and proceed from there.

[guardrex]

Sorry for the delay on this, but there's a lot of high priority .NET 7 work going on in the product unit repo. I'm also a bit 🏃😅 at the moment. We'll get back to this with an answer from management ASAP.

[giuseppe-terrasi]

Don't worry, but I think that the same problem will still be present in .NET 7. The improvement in the interaction with ASP.NET Core part sounds great but this implies that the user will be redirected while it is doing something and this is a bad user experience. If this could be done silently it will be more useful.
Thanks.

[guardrex]

I asked again, but there was no answer on it. I tend not to ask over and over ... and over again. 😄

In the past when this subject came up of what to say/show on actually working with the refresh token on the Blazor side, the answer was (I think from Javier) ... I'm paraphrasing from memory here ... the answer was that this is an advanced subject that is highly dependent on the context and can't be cleanly/quickly/easily covered by documentation. Devs will need to work out the code for their scenario(s) based on their knowledge of security concepts ... including with use of the MS security/Identity docs (here and in the MS Identity Platform/MSAL docs) ... including with access to the source code (here and in, for example, MSAL docs) ... including with the help of the community, if needed.

It seems to me that the best general approach is to take Javier's advice that I remarked on earlier from the PU comments.

Management ultimately decided that I should only perform a quick review and update of our Blazor security docs. They might be planning a major Blazor security review for possible major updates later ... 12-24 months out. I don't think it would be a good idea to spend a month overhauling docs for something that might change quite a bit in the framework. I'm not sure if that's going to happen, but I do know that I'll only be making a quick pass on #24615 and a lighter/quicker set of updates. I'll probably research the refresh token aspects a bit further on that effort, and I'm going to mark this issue there to make sure that I don't forget about this.