Description
The OAuthHandler class does not provide any option to expire the underlying Cookie ticket upon expiry of the Bearer Token, also it does not have any support for Refresh tokens other than storing the value in AuthenticationProperties.
I Suggest the following:
Add a property: bool ExpireUponTokenExpiry to RemoteAuthenticationOptions
On authenticating ticket, check this property
if false just return AuthenticateResult.Success upon validating the ticket
if true and bearer token is not expired return AuthenticateResult.Success
if true and bearer token is expired
-> if refresh_token isSet in AuthenticationProperties, Exhange the refresh token for new bearer token through http backchannel,
-> if no refresh_token is set, start a new OAuth authentication flow, with RedirectResult
Activity
Tratcher commentedon Mar 4, 2019
The UseTokenLifetime OIDC option already does part of this, tying the cookie lifetime to the token lifetime, though most people don't like it and have turned it off.
The biggest gap in the suggested design is that RemoteAuth.AuthenticateAsync doesn't run every request, it only runs during sign-in. After sign-in it's CookieAuth.AuthenticateAsync that runs every request and it doesn't know about the upstream details.
The other big gap is that refresh is not a well standardized behavior for OAuth. I tried it with a few of our common providers and only two out of five were able to share any of their logic. This was my last experiment at refresh: https://github.com/aspnet/AspNetCore/blob/39e52578d354a6a7abb3f6169d5ac2174ffe4551/src/Security/Authentication/samples/SocialSample/Startup.cs
We do need to provide better refresh support, but I doubt it would ever be completely automatic. A big reason is concurrency. If you have any parallel requests from the same user they would all start attempting the refresh as soon as the token expired. A better pattern I've seen is to only refresh the token when you go to use it. That cuts down the concurrency as you only use that token on a small subset of requests.
Eilon commentedon Mar 26, 2019
Placing in backlog so we can consider in a future version.
AdamWyzgol commentedon Sep 22, 2024
really still in backlog? since 2019?
halter73 commentedon Sep 27, 2024
Moving out of backlog for consideration in .NET 10. We could look at CookieOidcRefresher for inspiration although that's specifically for the
OpenIdConnectHandler
rather than theOAuthHandler
. It would be nice to add refresh support to both.#55213 is related but even tricker because in the case of Blazor Server interactivity it's harder to store the refreshed tokens in an updated cookie
Fronix commentedon Nov 8, 2024
For anyone who keeps returning here hoping for some type of revelation:
https://github.com/DuendeSoftware/Duende.AccessTokenManagement has created something that seems to work and has working examples...
josephdecock commentedon Nov 8, 2024
Thanks for the shoutout @Fronix! I'm one of the maintainers of Duende.AccessTokenManagement, so I thought I'd chime in. We're an apache licensed library sponsored by Duende Software for automatically managing access tokens.
In addition to simple token management, we also have support for DPoP (sender constrained tokens). And we have an extensibility point for storing tokens outside of cookies (especially helpful for Blazor Server).
developer9969 commentedon Dec 16, 2024
@josephdecock Hi come across this thread and also used in a pluralsight course I have just watched, my question is , is the accesstokenManagment nuget free to use in commercial application?
brockallen commentedon Dec 16, 2024
Yes, Apache2.
https://www.nuget.org/packages/Duende.AccessTokenManagement
9 remaining items