Identityserver4: SessionIdCookie being removed after login process after updating to IS4 2

[ericgreenmix]

I have been working on updating an application from IS4 1.5 to IS4 2.

The client uses the oidc-client js library with an Implicit grant type and has session monitoring turned on.

After updating to IS4 2, I noticed my client application refreshing every ~10 seconds. After doing much digging, I noticed that this was because the getCookies method in the check session iframe code was not finding any cookies, causing the session monitor to go call the authorize endpoint in an iframe, which caused the page to refresh.

Looking at the DefaultUserSession, I found this commit https://github.com/IdentityServer/IdentityServer4/commit/64139892d04d18ffbb43eb76d918e0d9d93ab121#diff-5edf6db6e6e0e5137e2fb539e0ca75d7

This commit adding RemoveSessionIdCookieAsync seems to be the culprit of the sessionid cookie getting removed.

Looking at the request flow when logging in from my client application, I see the following:
public/login -> RemoveSessionIdCookieAsync is called
connect/authorize/callback -> IssueSessionIdCookie is called
.well-known/openid-configuration -> RemoveSessionIdCookieAsync is called
.well-known/openid-configuration/jwks -> RemoveSessionIdCookieAsync is called
connect/userinfo -> RemoveSessionIdCookieAsync is called
connect/checksession -> RemoveSessionIdCookieAsync is called

So with that request flow, the SessionIdCookie gets removed, which causes the CheckSessionIframe in the oidc-client to try to reconnect and refresh because it can't find it.

Please let me know if I can provide any other details.

[brockallen]

.well-known/openid-configuration -> RemoveSessionIdCookieAsync is called
.well-known/openid-configuration/jwks -> RemoveSessionIdCookieAsync is called
connect/userinfo -> RemoveSessionIdCookieAsync is called
connect/checksession -> RemoveSessionIdCookieAsync is called

Can you investigate why on these calls the user does not have a session? If in those calls to IdentityServer there is no authentication cookie, then the session id cookie should be removed (if present).

[ericgreenmix]

Hmmm, yeah it looks like no cookies are being sent with the request in those 4 calls. Any idea on what could be causing that?

I verified that the .AspNetCore.Application.Identity and idsrv.session cookies are both set on the domain when those requests are being made.

[brockallen]

Any idea on what could be causing that?

IE zones, perhaps?

[ericgreenmix]

Using chrome

[brockallen]

Check your logs then -- maybe ASP.NET Identity is rejecting their cookie when it arrives for some reason? Or did you check the HTTP network level to see if it wasn't being sent?

[ericgreenmix]

It isn't being sent at the network level

[ericgreenmix]

At the start of the first .well-known/openid-configuration request the client has redirect from the IS4 domain to the client domain. It seems that there is something blocking the XmlHttpRequest that the oidc-client makes from reading/setting the cookies for the IS4 domain.

[brockallen]

It's odd that it blocks the cookies from being sent, but happily processes the response to remove the cookie.

[brockallen]

But yea, it's unclear to me what the issue it. Please keep digging.

[TomCJones]

.well-known/openid-configuration should be able to work anonymous as well as w/I a session

[ericgreenmix]

Okay, so you are right Brock. The cookies are not getting removed, because they aren't being sent in the first place. I have narrowed this down a bit more to what the issue is.

When connect/checksession is called, it is sending all the current cookies, EXCEPT for .AspNetCore.Identity.Application. The AuthenticateAsync method gets the cookie scheme and handler (which is the Identity.Application scheme) and since that cookie is not present, it is removing the idsrv.session cookie.

[ericgreenmix]

This is what my cookies look like when the checksession call is made

[ericgreenmix]

Could it be that the Lax Same Site policy on the .AspNetCore.Idnetity.Application cookie is blocking it from being sent from the iframe checksession request?

[ericgreenmix]

Looks to be the case:

[ericgreenmix]

So the Same Site Cookie attribute is currently only supported in Chrome. https://caniuse.com/#feat=same-site-cookie-attribute

I just verified that everything works fine in Safari and Firefox right now. It is only Chrome that is causing this issue because of the lax setting on the aspnet Identity cookie.

Is there some type of work around that can be put in place to make session monitoring work in browsers that support same site cookie attributes?

[brockallen]

Which cookie is the identity server cookie? IOW, do you use our built-in one, or are you configuring your own?

[ericgreenmix]

Okay, so the root of my issue is that I was not using the IdentityServer4.AspNetIdentity library for Identity integration. That library adds this line of code now https://github.com/IdentityServer/IdentityServer4.AspNetIdentity/blob/dev/src/IdentityServer4.AspNetIdentity/IdentityServerBuilderExtensions.cs#L48 to turn off the SameSite for Aspnet Identity.

Also, since I wasn't overriding the IUserClaimsPrincipalFactory like that library does now, the idsrv cookie was getting named .AspNetCore.Identity.Application because it was using the Aspnet Identity default factory.

With these changes, I now have everything working as it should. Thanks for your help!

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.