Server side session has incorrect expiration in certain scenarios

[acasciani]

Which version of Duende IdentityServer are you using?
This has been tested on version 6.3.0 but also found in earlier versions as far back as 6.1.7

Which version of .NET are you using?
.NET Core 6

Describe the bug
We have server side session configured in IdentityServer and are using sliding expiration on the authentication ticket. We are using the default CookieAuthenticationHandler used with Identity Server. We are seeing that when the authentication ticket is first granted for a session, the time span between the session's Renewed and Expires column (e.g. 2 minutes) matches the time span between the ticket's issued and expires values. When we call a session coordination action (e.g. refresh token on a JWT), we see that the server side Renewed and Expires updates accordingly and the timespan matches (e.g. 2 minutes). However, when we SSO with the OP a second time, the server side session now reflects a timespan between Renewed and Expires that is greater than the expected 2 minutes.

To Reproduce

For reference, I am looking at the renewed and expires in this table select "Renewed", "Expires", * from smsoauth."ServerSideSessions"

1. SSO in with OP, this creates a new authentication ticket with .NET core. Created: 19:57:05 Renewed: 19:57:05 and Expires: 19:59:05 and grab the access token (note: the AT expiration is 1 minute, so AT Expiration: 19:58:05)
2. Call the refresh token endpoint once the AT expires. The server side session columns are now Renewed: 19:58:08 and Expires: 20:00:08. Everything looks good so far
3. SSO in with the OP a second time at 19:59:14 .NET Core 6 is extending the authentication ticket based on the Issued time in step 1. Debugging through CookieAuthenticationHandler shows that the properties.IssuedUtc = 19:57:05 and properties.ExpiresUtc = 20:00:14. This looks to happen because .NET Core is not using the most recent Duende renewed time as their issued time, instead they are using the one from the previous web action (e.g. login from step 1). Since the request is made 3 minutes from that last action, the authentication ticket is updated to extend 3 minutes from the current time. Duende takes this value and stores that in the database.

Expected behavior

Ideally, the Duende server side session is always extended the same amount each time regardless if a server action was invoked (e.g. refresh token or user profile call) or if a authentication action (e.g. SSO/login) occurred. I think this means Duende can not rely on the Issued and Expires values coming from the authentication ticket. Please let us know if this is not the intended behavior with Duende's server side session or if this is a bug.

[josephdecock]

This does appear to be a bug.

The cause of the bug is that the session coordination service doesn't update the ticket in the session, instead relying on the deserialization of the ticket to update the ticket based on the session data. This is convenient, because we can update the session without needing to deal with the serialization and dataprotection of the tickets. However, the bug is that the issued time of the ticket is not respected as part of the deserialization logic. This results in a ticket that has a longer expiration time and therefore slides for a greater amount of time.

[acasciani]

@josephdecock I tested the change locally and it resolved the bug there. I'll be on the lookout for 6.3.1

[brockallen]

PR merged.