Consider an eager token refresh feature

[AndersAbel]

With server side sessions on IdentityServer the refresh token flow not only provides new access tokens, but it also ensure that the session on IdentityServer is kept alive.

Consider adding a feature that checks the token expiry time during the cookie principal validation and runs the refresh token flow if needed.

[brockallen]

I think this can be done manually today by calling GetUserAccessTokenAsync and pass the "force renew" flag on the options.

[AndersAbel]

It cannot be done from the cookie ValidatePrincipal event, because GetUserAccessTokenAsync calls AuthenticateAsync which results in a call to ValidatePrincipal. We can reuse the same code internally, but we need to provide an entry point that uses supplied principal and properties instead of getting them from AuthenticateAsync.

[brockallen]

Ok, that makes sense. But we still have a way now to do that as needed/desired. Also, this is how it was done in oidc-client-js, and it caused other issues. We can discuss.

[MH61Aus]

Just wanted to add to the discussion here, as it was my ticket that led to this.

We've followed the guidance around inactivity timeout (https://docs.duendesoftware.com/identityserver/v7/ui/server_side_sessions/inactivity_timeout), as we're in an industry where we'd prefer to end the sessions of inactive users as soon as we can.

Some of our clients don't hit web APIs, so their interaction with the identity server is limited to receiving their ID token (and subsequently claims via user info). for these, the identity server cookie expiration will never slide, as the tokens never get refreshed, so when the session cleanup service kicks in, the user gets signed out of the client even if they're doing stuff.

We added code in the cookie event handler validate principal to check for valid tokens, and refresh them if required in order to extend the session. we wanted to leverage AccessTokenManagement as its code already did everything we needed, but the call to Authenticate in AuthenticationSessionUserAccessTokenStore.GetTokenAsync would create an infinite loop.

For now we've created our own extensions of this code, such as ICustomUserTokenManagementService: IUserTokenManagementService which defines Task<UserToken> GetAccessTokenAsync(CookieValidatePrincipalContext context, UserTokenRequestParameters? parameters = null, CancellationToken cancellationToken = default);

For the most part the only real difference is that this code assumes that since you have a CookieValidatePrincipalContext, you don't have to authenticate again.

As an aside, I added IntrospectAccessTokenAsync to our ICustomUserTokenEndpointService

and in GetAccessTokenAsync I added a call to this introspection endpoint to see if a token had been revoked.

This all seems to be working great at the moment. I'm not sure if its seen as totally out of scope for the AccessTokenManagement library, but I'm surprised others aren't running into the same issues we did.