Oidc-client-js: CheckSession fails with local SPA and IdentityServer in Azure

[Granatenhoschi]

Hello,

I have a SPA based on Angular4 and an IdentityServer4, both deployed as Azure WebApps. The SPA requires authentication to the identity server via oidc-client.js. Everything works fine so far except for one specific szenario:

When running the SPA locally in Internet Explorer (my current version: 11.1176) against the in Azure deployed identity server the check session call fails with 'Response was error: login_required'. SSO still works in the browser, so in my eyes the user session is still valid and I see no reason why the identity server prevents the check session call with info 'prompt=none was requested but user is not authenticated'.

For all other browsers everything works fine. When using Internet Explorer with local SPA and local identity server or Azure deployed SPA and Azure deployed identity server everything works fine, too.

Any ideas?

[brockallen]

Possibly a IE zone issue? IOW, 2 of the hosts are in different zones, do IE does not send the auth cookie in the iframe?

[Granatenhoschi]

Doing some research regarding zone-blocked cookies in iframes with IE, this seems to be a plausible explanation for my issue. Unfortunately I was not able to verify it: trying to allow the cookies via browser settings or via p3p headers did not fix it for me. Nevertheless, I would not be happy dealing with such workarounds for an issue which only has effect in my rarely occuring testing scenarios with IE where I easily also am able to authenticate against a local identity server and everything works fine.
I won't do any further investigation so in my eyes the issue can be closed.
Thanks for your support.

[PeterHageus]

I have the same problem, but in Chrome. Can not find a way to enable cookie access for iframe (not sure if this is even a thing in Chrome).

The problem only occurs when running locally against IdSrv4 2.1.1, it works fine with 1.5.1.

Checksession fails, and triggers a silent refresh (even though automaticSilentRenew is false), and user is logged out immediately again.

Same messages as OP:
Response was error: login_required
Showing error: prompt=none was requested but user is not authenticated

[brockallen]

Sounds like you need to enable lax same-site cookies for the auth cookie.

[PeterHageus]

Could not find that exposed anywhere, so tried replacing IConfigureNamedOptions, but made no difference. (it gets called though, so lax should be active)

[icistrate]

I am having same issues after I upgraded IDS from 1.5 to latest 2.x .. I just have my own cookie

@PeterHageus did you find any solution?

@brockallen could you show small example how to do that? (you mean this: opts.Cookie.SameSite = Microsoft.AspNetCore.Http.SameSiteMode.Lax .. this is already the default value)

[PeterHageus]

@icistrate nope, there is obviously something I don't quite understand about the auth configuration. Have tried numerous ways to set it up, no difference. Think it's more of an ASP.NET Core issue than IDsrv though.

[icistrate]

@PeterHageus yes indeed..

I am actually trying this in development server and I already get something working, but would be nice to understand bit more what is behind:

          .AddCookie(STR_COOKIE_NAME_IDS, opts =>
          {
                    opts.ExpireTimeSpan = VAL_COOKIE_DEFAULT_EXPIRATION;
                    opts.LoginPath = new Microsoft.AspNetCore.Http.PathString(AppHelper.LocalUrl(STR_ROUTE_MAIN_AUTH_IN));
                    opts.Cookie.SameSite = Microsoft.AspNetCore.Http.SameSiteMode.None;
                    opts.Cookie.HttpOnly = true;  
                    //opts.Cookie.SecurePolicy = Microsoft.AspNetCore.Http.CookieSecurePolicy.None;
          });

I am not completely sure how CORS rules defined in IDS through .AddCorsPolicyService<>(), play along these cookie settings..

[jalchr]

I'm facing the same issue. Once I use a domain name different than localhost, the silent renew fails.
Latest version of IdentitServer4 (v2.3.2).
After successful login in Chrome (v71), it auto-logs out.
Anyone got this working ?

[jalchr]

P.S: Why are issues closed so fast?
People are facing similar problems for periods of time longer than the initial submission of the issue. True, it might not be related to the "core", but still GitHub issues are a kind of "Crowd Support" location.
May be the labeling is wrong ... may be it should "unresolved" / "concerning" rather than "question" ?

[victormp1988]

@jalchr we are suffering same problem. Any solution?