Bug 266744 – Safari 17+ Anti Tracking feature breaks walmart.com OAuth

• Status: RESOLVED
• Resolution: FIXED
• Component: Platform

[cdaringe]

- A clear description of the problem

Users cannot login via walmart.com.

In Safari 17+ private browsing sessions, all query params are stripped during cross-domain navigation, breaking critical OAuth authentication flows for Walmart business.

- A step-by-step set of instructions
I posted this report to Apple Feedback via FB13481858, however, it may be more appropriate to post here. Please assist in closing whichever report is less relevant, and engaging in the report that is more relevant.


> What does the Safari issue you are seeing involve?

Private Browsing

> Please provide the URL to one or more websites where you are seeing this problem:

https://www.walmarthealth.com/vc/getVirtualCare

> What extensions or content blockers do you have enabled?  Example: AdBlock, 1Blocker

None

> What time was it when this last occurred? (Example: 12:00 pm EST 02/14/2018)

Dec 20, 2023 at 12:21 PM

> Please describe the issue and what steps we can take to reproduce it:

Perform the below steps inside and outside of Safari's private browsing mode.

1. Visit a Walmart owned web URL, such as https://www.walmarthealth.com/vc/getVirtualCare
2. Click the “Login” button.
2a. When clicked outside of private browsing, the visited URL should take the general form: https://www.walmart.com/account/login?client_id=OAUTH_CLIENT_ID&state=RETURN_STATE&redirect_uri=RETURN_URI&scope=OAUTH_SCOPE&nonce=NONCE. These query params are clearly used for authentication, not for tracking purposes.
2b. When clicked inside of private browsing mode, all critical query params are removed, breaking OAuth capability.

- What result you expected

I expected my URL search parameters to not be deleted.

- What results I saw

Safari removes critical authentication inputs from the URL search params.
The end result is that my OAuth workflow does not complete, and the user does
not return to the OAuth integrating site with the expected OAuth datas needed
by the OAuth integrator.

- Research

It was just shared with us (mid report) that https://webkit.org/tracking-prevention-policy/ calls out “unintended impact” for “Federated login using a third-party login provider.” We can investigate alternate mechanisms, however, even our most-web-aware experts were caught by surprise by deleting this foundational browser I/O mechanism. Other documents in the apple ecosystem have stated that the feature removes known tracking queries. Can a known set of OAuth params be permitted? What guidance do you have for us as consumers of standard web APIs to implement standard web flows for which you no longer support?

"We may alter tracking prevention methods to permit certain use cases, particularly when greater strictness would harm the user experience". Breaking logins by altering web standards seems like harming the user experience, albeit this is certainly perceived as subjective given the nature of the entire feature.

[Radar WebKit Bug Importer]

<rdar://problem/119962725>

[John Wilander]

Thanks for filing! I’d be surprised if these query parameters are filtered out. Are you sure that’s the case and not just that JavaScript is unable to *read* the query parameters?

[cdaringe]

Yes, the failure mode is local to safari browser only with the aforementioned launch conditions. The Feedback ID has video uploads of this too. Lastly, its easily reproducible even on macos builds with 17+. ios not required.

[Charlie Wolfe]

Hi. This is caused by the query string being hidden from JavaScript following a cross-site navigation. We've added exceptions for these query parameters; they should no longer be removed in Safari 17+.

[cdaringe]

Thank you! Much appreciate. Is there a ref to GH commit we could inspect? I scanned through the first page of history and nothing jumped out at me as super relevant. Thx again