Oidc-client-js: Redirect Loop when Browser has Blocked Third Party Cookies

[loweware]

Some users of our Angular SPA are stuck in a redirect loop during login, and it has been narrowed down to the browser settings blocking third party cookies. IdentityServer and SPA are hosted on two different domains.

Is there an alternative login flow or other suggestions to support users who choose to block third party cookies?

The root of the redirect loop appears to be the CheckSession IFrame not being able to read the idsrv.session cookie, which generates a new hash and silent refresh loop.

Here is the SPA's UserManager config:

authority: oidcAuthInfo.authority,
client_id: oidcAuthInfo.clientId,
redirect_uri: ${baseHref}auth-callback,
silent_redirect_uri: ${baseHref}silent-refresh.html,
post_logout_redirect_uri: ${baseHref}welcome,
response_type: 'code',
scope: openid profile ${oidcAuthInfo.apiName},
filterProtocolClaims: true,
loadUserInfo: true,
revokeAccessTokenOnSignout: true,
automaticSilentRenew: true

[brockallen]

That's a requirement of how the OIDC specs work.

[loweware]

Is there any guidance around preventing the session management iframes from getting into a loop when third party cookies are blocked, in order to avoid avoid excess network traffic and/or page refreshes by end users?

[brockallen]

Use the main window, not an iframe. Or use refresh tokens for renewal (but protect that: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04#section-8).

[jcd79]

iOS Safari has the setting "Prevent Cross-Site Tracking". It's turned "On" by default.
This applies to both iOS version 12.x and version 13.x.

But this redirect loop, for us, only happens on version 13.
Is this a known problem?
For us this fails in both a SPA application using old Angular/Knockout js, but it also fails in a fresh SPA application that uses React.
Both of the SPA's work with iOS 12.x, but on iOS 13.x there is a redirect loop.

Tried this: https://www.thinktecture.com/identity/samesite/prepare-your-identityserver/
But does not seem to help for this issue.

[jcd79]

Solved this for now by setting
var isIOS = (/iPad|iPhone|iPod/.test(userAgent) && !window.MSStream;
automaticSilentRenew = !isIOS
monitorSession = false

[ericgreenmix]

@jcd79 I created a new issue with #1074 to track this. We are hitting the same thing with Safari.

[luisfrocha]

I'm currently getting the same, but using Chrome, but not sure if it's the same thing

[jjavierdguezas]

this is happening now with Chrome Version 83.0.4103.116 (Official Build) (64-bit) on incognito mode

[brockallen]

Yep, that's how things are now.

[Roach6996]

How we can fix the above mentioned issue for chrome?
on iPhone, after login I am stuck with redirection infinite loop (only on chrome, works fine on safari)

[jeroenheijmans]

How we can fix the above mentioned issue for chrome?

@Roach6996 You can't, not really.

I've written about the current workarounds/"solutions" I see (I'm an web app developer though, not an IDS expert), loosely based / using input from the excellent leastprivilege.com blogpost "SPAs are dead!? (who is I believe a colleague from brockallan, and they _are_ IDS experts I'd say). Hope that helps. To summarize, the five main directions I currently see:

1. Serve IDS via a subdomain of your SPA's domain
2. Proxy your IDS for your SPA via the SPA's domain
3. "BFF" (Backend For Frontend) architecture, also mentioned by leastprivilege's blog
4. Use new Browser API's like the "Storage Access API" and inject its functionality in the client side library
5. Fall back to using Refresh Tokens (with appropriate extra security measures)
6. ??? I surely have missed options.

None of the workarounds/solutions would involve changes to the client side libraries (except _maybe_ 4, which is not as useful as it sounds because of browser support), as far as I can tell. All of them are about rethinking your architecture in varying degrees. For my current project we use option 1, which seems to work out with some tweaks here and there.

[Roach6996]

@jeroenheijmans I have implemented point 1 already. But still it doesn't work on chrome(iPhone)

[pmoleri]

Hi @jeroenheijmans

Thanks for your blog, it's a nice summary of solutions and tradeoffs.

If I understand correctly, all options other than 4, will establish an independent session from the main domain, right?
Meaning that session at identity.example.com and product.web will be independent from one another.

I'm interested in options that preserve SSO between both domains:

• Option 4: Use new Browser API's like the "Storage Access API" and inject its functionality in the client side library
  (not sure if can be implemented in Chrome)
• Option 6: BFF architecture + disable Session monitoring + Back-channel Logout
  see related info in session management spec

I'd appreciate any comments on this options or other viable options that preserve SSO.