Inconsistent login status across multiple clients

[robnelder]

I'm more than 90% sure this is an issue with the way I'm configuring IdentityServer and/or client apps rather than a bug with IdentityServer, but the docs refer me to this forum for standard support so here I am. Please let me know if I should be asking this somewhere else like stackoverflow instead.

Which version of Duende IdentityServer are you using? 7

Which version of .NET are you using? 8

Describe the issue

We host our own IdentityServer instance and all client apps are our own.

When a user changes between client apps some time after logging in, some apps consider the user to be logged out while others consider them to be logged in. This is confusing and inconvenient for the user. I think we have probably always (4-5 years or so) had this issue but it has recently become more apparent as we now have multiple clients sharing a host URL behind a reverse proxy.

Setup/Configuration

Our clients are all configured to have a 20 minute id_token, 5 minute access_token and 30 minute refresh_token, most clients use a response type of code with PKCE, an older client uses hybrid flow with code id_token. They use session cookies with a sliding expiration as we want the browser to delete them when the browser is closed.

To Reproduce

1. Open Client A and login.
2. Open Client B in a new tab (no need to log in as already logged in).
3. Refresh a page on Client A every 10 minutes, which keeps the login session alive on Client A.
4. After more than 20 minutes, refresh a page on Client B - this client will consider the user to be logged out.
5. Open a third tab for Client C (no need to log in as already logged in due to Client A keeping the login session alive).

At this stage:

• Client A on the first tab considers the user to be logged in.
• Client B on the second tab considers the user's session to have expired and treats them as not authenticated.
• Client C on the third tab considers the user to be logged in.

It appears as though Client B is aware that it has been used and that its id_token has expired, but is unable (or doesn't try) to acquire a new one from IdentityServer. Client C which came along later seems to be able to get tokens from IdentityServer just fine as the user login session is alive due to the user continuing to use Client A.

Desired behaviour

If the user has been actively using any of the clients, we would like all clients to behave as though the user is logged in (at least from the point of view of the user's perception). This is more important now that we have clients sharing a URL host, as from the user's point of view they look like one application, some parts of which are logged in while others are not.

How can we achieve this? Please help or point us in the right direction.

[robnelder]

I've spent a lot of time trying to research and test this issue by handling OIDC events and cookie authentication events.

Firstly there's a correction to make regarding the outcome I describe above. Following those steps, Client C also considers the user to be unauthenticated.

I think that the issue I have here is that my client apps each effectively manage user idle timeout independently of each other, and that their own session cookies are managing the user session lifetime once they are logged in rather than IdentityServer. I wonder if using something like Duende's Server Side Sessions Inactivity Timeout functionality might provide a suitable solution. I think this example of a custom server side SessionStore might also work.

Can anyone provide any thoughts, opinions, or better still - advice on either of these options? Could Duende's Server Side Sessions enable user activity in any client app to be recognised as a non-idle user across all apps and therefore enable a given client to be re-used after a long time spent in another client, without requiring the user to log in again? If we were to use Duende's Server Side Sessions, is there someone we could go to for help or consultation on how to implement that in our system(s)?