How to limit server side sessions

[0472d]

We would like to limit the maximum session time to 8 hours. We have server side sessions enabled and i can see sessions that are 20 days or more. I do understand that is normal for oauth etc. But we have a requirement to limit sessions max time and limit multiple sessions. Multiple sessions is easy as we can check during login if an old session is running and kill it using your sessionManagementService. Our issue is limiting the max session time to 8 hours.

As a POC we are trying to limit to 5 mins for testing. We have tried various things, however i can see the server side sessions are being extended. In this POC we just have ID server and a react front end calling .NET APIs using a reference token that has a 5 min lifetime that gets a new token via an iframe. Getting this new token seems to be extending the serversidesession by 5 mins each time.

Is there a simple way of saying that the server side session can only last 5 mins and cant be extended?

[ProgrammerAL]

Hello, you should be able to control the session’s maximum lifetime by setting the lifetime of the client’s refresh token. Setting the client’s AbsoluteRefreshTokenLifetime property to 8 hours (28,800 seconds), and the RefreshTokenExpiration property to TokenExpiration.Absolute should get what you’re after https://docs.duendesoftware.com/identityserver/reference/v8/models/client/#refresh-token

If you have tried this and were unsuccessful, can you elaborate more on what various things you have tried?

[0472d]

Thanks for the info. I was hoping to avoid changing clients and have been playing with ServerSideSessions (SSS) and cookies only. We needed to limit how long they can stay logged in the ID server so they cant just redirect and get a new token. We think that part is sorted, however it was the clients refreshing the SSS that is stumping us.

I was hoping we could set something on the SSS to limit to 8 hours which would affect all clients. However what you are implying, i.e. have to set the client max time, is essentially what we have seeing. We did find when we deleted the SSS user session this blocked the client and was hoping we could do something with a max SSS time that would stop the renewing.

Unless you can point us to anything on the SSS that will do this, we will check out the client settings next.

[wcabus]

@0472d, are you looking for a solution that would (potentially) affect every client on the IdentityServer level? Or are you looking for a way to only limit the session's lifetime for this specific client application?

Additionally, just to confirm: is the React app hosted in a backend-for-frontend setup, or is the React app interacting with IdentityServer as a public client (without a client secret)?

[0472d]

We are looking for a solution which could affect every client. We are aware it will only work if the client does any form of regular token checks or supports a backend logout. We support over 100 clients all using a mixture of tech, different oauth flows, SAML. We are hoping to cover the majority of the clients that make regular checks.

The POC is a public client without a secret, the backend API it calls has an API resource secret,

[ProgrammerAL]

As a global approach, you can set the lifetime of the cookie for Server-Side Sessions https://docs.duendesoftware.com/identityserver/ui/server-side-sessions/session-expiration/#configuring-server-side-session-lifetime, and also disable the sliding cookie expiration. This doesn’t require making a change to any clients.

You can configure it the IdentityServer way with:

builder.Services.AddIdentityServer(options => {
	options.Authentication.CookieLifetime = TimeSpan.FromMinutes(42);
	options.Authentication.CookieSlidingExpiration = false;
});

Or the ASP.NET Core Identity way

builder.Services.ConfigureApplicationCookie(options =>
{
	options.ExpireTimeSpan = TimeSpan.FromMinutes(5);
 	options.SlidingExpiration = false;
});

[wcabus]

Just make sure that none of the clients have the CoordinateLifetimeWithUserSession option enabled (or the global setting CoordinateClientLifetimesWithUserSession).

When a client has lifetime coordination enabled, that client could again extend the server-side session, which could affect other clients as well, even if they didn't enable lifetime coordination.

[0472d]

Thanks both for your answers, Setting the cookie lifetime is what we have been experimenting with, but its the CoordinateClientLifetimesWithUserSession thats probably broken it. We have set this because we took this to mean if the SSS expires or is deleted it would also block the client. It certainly does if the SSS is deleted. But what wcabus has just said is exactly what we are seeing.

Have reread that page and something has now clicked.....

"As the client uses the refresh token at IdentityServer, the user’s session expiration will be extended. Be sure to configure the access token lifetime to be less than the server-side session lifetime at IdentityServer."

So we will have to set the absolute max client times as well due to this setting. I am assuming if we dont coordinate with the SSS then if we delete an SSS entry the client would carry on working as its not linked to SSS.

Will do some more tests with not having Coordinate set, but i think the most likely to work will be setting the cookies, setting absolute limit on client and coordinating the SSS.

Will report back in a couple of days... Thanks for the info.

[0472d]

Wow 3 weeks already....

Have been doing some playing. Have found a way to do what I want but is a little unconventional.

All the clients are set to CoordinateClientLifetimesWithUserSession. We set them to 8 hours max. We also set the cookie lifetimes to 8 hours. The problem with this setup is if the user went to a new app at 7 hours. This new app has eight hours from when it started which still extends the serversidesession so end up with lasting 7 + 8 hours. If they went to another app again it extends it again. We have over 100 apps connected.

We have another issue related to the serversidesessions table. Occasionally our DB connections spiral out of control, we think its related to clearing the sessions blocking new ones as we have multiple web servers all trying to do it at the same time. I have disabled the auto cleanup and have written a windows service which every 2 seconds queries the SSS table to get top 5 expired sessions using with NOLOCK. We then call the sessionManagementService.RemoveSessionsAsync one at a time to clear them. This does seem to be working, more time will confirm... This clears 5 sessions every 2 secs, 150 in a minute, 9000 an hour, 216000 a day, which is keeping up with our approx 100,000 users logging in a day.

While doing this we realised we can change the query to also get sessions that were created more than 8 hours ago. This is killing the session for us. Doing it this way means we dont need to worry about setting the clients to 8 hours max etc. The sessions will be cleared soon after. We have not released this yet just testing, appears to be working, can anyone see any issues with doing this?

[wcabus]

Personally, I don't see an immediate issue with this approach: it achieves your goal and sessions will be cleaned up, issuing back-channel logout notifications if necessary.