[Question] Inactivity Timeout, Session Lifetime and Refresh tokens : How to cater for different requirements across different Client applications

[andy-fitz]

Which version of Duende IdentityServer are you using? 6.2.3

Which version of .NET are you using? 6.0

Context Hi,

We are looking for some support on how Inactivity Timeout and Refresh tokens works for our client applications.

We have two categories of client:

• mobile
• web

For our mobile clients we want to be able to have long lived logins. I.e. a mobile user should be able to sign in once and remain logged in for about 2 weeks before having to sign in again.

For our web clients we need inactivity timeout to ensure that the user is logged out after 1 hour of inactivity.

We have been reading through the documentation and trying to determine how to achieve this but there does not seem to be an obvious solution.

We have globally enabled [CoordinateLifetimeWithUserSession], since web sessions must expire within an hour of inactivity and we need to ensure that all clients are logged out on sign out when one client logs out, but this means our mobile apps refresh tokens will not work after 2 weeks of inactivity.

We do not have back channel logout support. We use front channel logout.

An Option we are looking at As far as we are aware its not possible to configure different Session lifetimes per client since this is a shared resource and its globally configured on startup. One option that's been suggested in our company is to host two identity servers applications, each host would be configured with different Session lifetimes. So mobile could call their IDP and expect a 14 day session lifetime and web would call theirs and expect a 1 hour session lifetime. Both hosted applications would use the same IDP database and so the same Server Side Session store.

Questions

• Can you please help us determine if there is something obvious we are missing here and if there is in fact a viable solution to this catered for in identity server, anything alternative to the option above?
• Can you please advise if the option suggested above is viable or if there are any obvious issues with that?

Thank you

Related Documentation https://docs.duendesoftware.com/identityserver/v7/ui/server_side_sessions/inactivity_timeout/

Related Issues https://github.com/DuendeSoftware/Support/issues/391

[RolandGuijt]

Can you please tell us what kind of web application you have as a client? Is it server-rendered like an MVC or Razor Pages app or a SPA? If it is a SPA are you using the BFF pattern?

[andy-fitz]

Can you please tell us what kind of web application you have as a client? Is it server-rendered like an MVC or Razor Pages app or a SPA? If it is a SPA are you using the BFF pattern?

Hi @RolandGuijt, Thanks for the response.

Our current web applications are all SPAs and use Front Channel logout without BFF. JWT access tokens are stored by the SPAs themselves. We are planning to move to BFF pattern in the future but not before we need to tackle this issue.

Our mobile apps are both IOS and Android applications.

[RolandGuijt]

Thanks. If I understand correctly:

• Sessions for mobile apps should last for a fixed 2 weeks
• Sessions for web apps (non BFF SPAs) should have a sliding expiration of 1 hour
• When one session (web or mobile) expires the sessions for all other clients must end too (web and mobile)

Is this assumption correct?

[andy-fitz]

Thanks. If I understand correctly:

• Sessions for mobile apps should last for a fixed 2 weeks
• Sessions for web apps (non BFF SPAs) should have a sliding expiration of 1 hour
• When one session (web or mobile) expires the sessions for all other clients must end too (web and mobile)

Is this assumption correct?

Hi @RolandGuijt,

• Sessions for mobile apps should last for a fixed 2 weeks - Yes
• Sessions for web apps (non BFF SPAs) should have a sliding expiration of 1 hour - Yes
• When one session (web or mobile) expires the sessions for all other clients must end too (web and mobile) - - No, if somebody is signed in on their mobile under Session X and simultaneously is signed in on the laptop under Session Y then logging out of Session X should not effect Session Y and vice versa. Though if mobile app is signed in under Session X and they open up one of our web clients on the their mobile they will be both under session X and so logging out of session X will log out of both.

Thanks !

[RolandGuijt]

A solution to this is complex. The level of support required unfortunately goes beyond what we can offer in this issue tracker. If you want further help we could help out using our remote consulting offering. Please get in touch for more information about that.

[RolandGuijt]

Closing the issue for now. But if anything comes up around this issue where we can assist with in this issue tracker, please reopen.

[AndersAbel]

I might misunderstand the requirements, but I think that this should be doable with the normal configuration options.

If I get this right you want to coordinate the lifetime of the IdentityServer and the SPAs, but the mobile apps and their refresh token should be independent of the session on the IdentityServer?

I that case you can skip the CoordinateLifetimeWithUserSession setting - when using SPAs with iframe-based refresh/logout handling the sessions are coordinated by default and there is no refresh token. Then set the lifetime of the refresh token on the mobile app configuration to be whatever needed. It is a common design to let refresh token and thus the "session" of a mobile app survive long past the web based session that was used on the initial login.