Oidc-client-js: Safari 13 is blocking 3rd party cookies via its new Intelligent Tracking Prevention

Created on 24 Mar 2020  路  16Comments  路  Source: IdentityModel/oidc-client-js

Reference link: https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/

When the monitorSession or automaticSilentRenew iFrames are turned on in versions of Safari after 13.0.4, they are unable to access the 3rd party sessions cookie from identity server. This causes them not to be able to authenticate which then results in a redirect loop.

Per the reference link above:

ITP will now block all third-party requests from seeing their cookies, regardless of the classification status of the third-party domain, unless the first-party website has already received user interaction.

Is there a known workaround for this with the oidc-client?

question

Most helpful comment

All 16 comments

The long term solution will be to move to using refresh tokens with all the appropriate threat mitigation techniques.

https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps

This library already supports refresh tokens obtained via code flow + PKCE.

@brockallen Will that technique work for session monitoring since it is based on the cookie?

Good question. Possibly not. It's something that maybe should be raised with the OIDC WG.

Okay cool.

@brockallen Would you consider these Identity Server 4 refresh token settings as the recommended "appropriate threat mitigation techniques"?

RefreshTokenExpiration = Absolute
RefreshTokenUsage = OneTime
AbsoluteRefreshTokenLifetime = the default of 30 days

I think I've just run into this headlong myself. I get the login / immediate logout behavior on Safari and on IE11 when monitorSession it true (although I'm not sure why on IE11). Chrome, FF see to work OK. Just to ask again, if I would like Session Monitoring in IE11, what are my options? Is this going to be a roll your own kind of thing?

if I would like Session Monitoring in IE11, what are my options?

Build a backend for your frontend that OIDC back channel signout notification.

@brockallen Could the monitorSession call be implemented using the AccessToken or RefreshToken instead of relying on cookies? This Third Party Cookie Blocking is really making it a lot harder to implement oidc sucessfully for "the average developer".

@brockallen Could the monitorSession call be implemented using the AccessToken or RefreshToken instead of relying on cookies? This Third Party Cookie Blocking is really making it a lot harder to implement oidc sucessfully for "the average developer".

Not unless the OIDC spec changes.

I experience a similiar issue in Chrome Incognito mode, where the userSignedOut callback is triggered immediately after successfully signing in. This only occurs though when monitorSession is true (which it is by default).

@mediafreakch Yup, Chrome started doing it in Incognito and if I recall correctly in the future will also do this in normal mode. At the moment you _can_ turn it off in Incognito mode when you start the session:

image

Alas (for devs, for users and privacy this is all good news I think), this is the state of things.

I've written a blog summarizing possible mitigations (solutions?) _I_ see from which I'm using the "IDS on subdomains" option with some success at the moment, heavily inspired by @brockallen's colleague's (I think?) blogpost "SPAs are dead!?". Maybe those links are helpful for you and others.

As for this issue and the library, it's probably properly marked as a "question" and could possibly be closed? The best this lib could do at this point in time is probably to document guidance, is all.

How we can fix the above mentioned issue for chrome?
It's not working in normal mode too now.
on iPhone, after login I am stuck with redirection infinite loop (only on chrome, works fine on safari)

Again, this is a browser behavior and not much this library can do about it.

@brockallen Any work around to solve this issue on chrome (iPhone)?

@Roach6996 You need to read https://infi.nl/nieuws/spa-necromancy/ carefully and apply one of the suggested solutions. Moving the identity provider to a subdomain of the affected web-app solved the problem for us.

@mediafreakch Both my app and Identity server are already on same subdomain.
After login it enters into infinite loop on chrome.
Console shows http failure response for userinfo endpoint.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

wsimf picture wsimf  路  4Comments

StephenRedd picture StephenRedd  路  5Comments

tamias picture tamias  路  3Comments

shesellsanctuary picture shesellsanctuary  路  4Comments

arnaldo-infinite picture arnaldo-infinite  路  4Comments