IdentityServer
Question: SlidingExpiration of IDSvr Cookie
We are attempting to have our application use the slidingexpiration feature so that we can expire the ID token after a set amount of inactivity (e.g., 1-2 hours).
We have setup the cookie options as follows:
CookieOptions = new CookieOptions
{ ExpireTimeSpan = 3600,
SlidingExpiration = true,
IsPersistent = true,
AllowRememberMe = false
}
Sure enough activity will extend the expiration on the IdSvr cookie itself - but it does not appear to extend the expiration on the IdSvr.Session cookie - this cookie expires once the initial ExpireTimeSpan has been reached.
The issue that we are running into is that we are also using CheckSession to determine when the session has changed (and to implement a single sign-out operation of multiple applications using the same ID login token). When we receive a "Changed" event it indicates that we should remove the token because something has changed. The issue is that the CheckSession is using the IdSvr.Session cookie to create the hash it uses in comparison. Once that cookie times out (which it does after 1 hour in example above) the hash changes and sends a "Changed" event.
Should the IdSvr.Session cookie be utilizing the sliding expiration too? Is there another way that we can accomplish what we are seeking to do - and continue to use the CheckSession?
Any insight is appreciated.
Thanks,
John
Was wondering if anyone had a chance to look at this. Just wanted to see if you thought I was doing something wrong or if there may be an issue with the code?
Thanks,
John
I don't understand what your first statement means: "We are attempting to have our application use the slidingexpiration feature so that we can expire the ID token after a set amount of inactivity (e.g., 1-2 hours)."
I'm working with jsalig. I think he meant to say the Id Server session cookie in the first sentence.
The problem we're seeing is that the session id cookie (idsvr.session) is expiring before the primary authentication middleware cookie (idsrv) when the later is configured to use sliding expiration. When that happens the session id is no longer accessible and javascript clients are incorrectly notified that the session has changed when using the check session iframe.
I've confirmed this behavior using the sample client.
The session id cookie should be a "session" cookie, meaning that it lasts as along as the user's browser remains open. The value inside (the session id/sid) will change if the user logs out and logs back in again, or logs in as a different user.
What steps do you take where it's removed before the user changes their logged in user?
Using the following cookie options in identity server: new CookieOptions { ExpireTimeSpan = 120, SlidingExpiration = true, IsPersistent = true, AllowRememberMe = false }
Using the javascript implicit client sample with access token lifetime set to 90 seconds.
I click "login with profile and access token" and log in at id server and am redirected back to client. Every 30 seconds the client silently renews the access token which extends the sliding expiration window. After 2 minutes the following message appears in the console window "no check session url, user, or session state: not setting up check session iframe". When I check the cookies at the id server, the "idsrv" cookie is present, but the "idsvr.session" cookie is not.
Looking at https://github.com/IdentityServer/IdentityServer3/blob/master/source/Core/Configuration/Hosting/SessionCookie.cs, I can see that the idsvr.session cookie is created with an expiration time the same as the primary authentication cookie, in this case 120 seconds. But I can't find anywhere in the IdentityServer code where the idsvr.session cookie has its lifetime extended when the primary authentication cookie's lifetime is extended.
I am also getting similar issue so just wanted to know if this issue has been fixed?
Is this still an issue? I feel as though I am getting similar behavior.
This is something that we will target for 3.0 -- it's a behavioral change the to cookie handling.
We have an IDS 3 in production and would like to use the sliding expiration as described in this issue.
Do you have a release date for 3.0?
Do IDS 4 have the same cookie behaviour, or will a switch to IDS 4 solve our problem?
