IdentityServer3 icon indicating copy to clipboard operation
IdentityServer3 copied to clipboard

Why is the idsrv.clients cookie not persistent?

Open FireFly26 opened this issue 8 years ago • 7 comments

Dear,

We have an STS that is used by multiple MVC apps. All these are setup with a LogoutUri so that when a user logs out in 1 app, Identityserver can generate an iframe to log out from all apps this user has logged in to. This works perfectly as long as the user doesn't close his/her browser. After some digging I found that the idsrv.clients cookie is used to keep track of all the apps a user logs into. And when a logout request is received, the clients cookie is used to generate the logout iframes. But I also found that the clients cookie can't be set to persistent. So the "logout cleanup" doesn't work if the browser was closed while logged in.

Am I doing something wrong here or is this by design?

Kind Regards, Steven.

FireFly26 avatar May 31 '16 13:05 FireFly26

We have the same issue here, our customer want's the cookies to be persisted because of the behavior of the behavior of the previous identityserver did the same.

jancorluy avatar Jun 01 '16 14:06 jancorluy

This was originally deliberate, since IdSvr has no idea how the client does its session management. We could consider making the client list cookie persistent.

brockallen avatar Jun 11 '16 15:06 brockallen

Any plan when this can happen?

Thx, Steven.

FireFly26 avatar Jun 20 '16 09:06 FireFly26

Haven't even had time to think about it. I'd need to spend the time thinking thru all the possibilities if there cookie were changed to persistent.

brockallen avatar Jun 20 '16 11:06 brockallen

ok, thx for the update.

FireFly26 avatar Jun 20 '16 12:06 FireFly26

@brockallen -- I'm having a hard time understanding the utility of single sign off if the client list is not a persistent cookie. In what situations does single sign off work with identity? Only in the case where its performed in the same browser session?

With client list being session based, doesn't this mean that the only way to offer a consistent single sign off experience is to enforce (not that you can) all your clients implement their own session based cookies for storing user state?

It also seems that in order to guarantee reasonable behavior with sign off, any client would have to destroy their cookies before redirecting to identity because they can't rely on the client list being accurate and hitting their own LogoutUri?

EDIT: Just discovered that on mobile devices session-based cookies can last a long time (i.e. until a user reboots their device)

philipbjorge avatar Jul 14 '16 00:07 philipbjorge

Any update on this, or any clarifiaction? For me it seems that this breaks a lot..

senj avatar Jul 28 '16 13:07 senj