[Webkit-unassigned] [Bug 217670] Safari blocking third party iframe cookies

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=217670

--- Comment #1 from John Wilander <wilander at apple.com> ---
(In reply to Amol Patel from comment #0)
> We are running into a pretty unique issue regarding Safari blocking our
> third party cookies from an iframe. Here is our situation:
> 
> A user is authenticated into an application example.com and clicks on a tab.
> The tab renders a page that contains an iframe which is pointed to
> SiteA.com's launch URL to start an OAuth 2.0 SSO handshake. After
> successfully authenticating the user, SiteA.com will redirect the user to
> its home page. SiteA.com will set all cookies with SameSite set to None and
> Secure to True. As of now, Safari rejects the cookies so SiteA.com can not
> load on example.com in an iframe. We was hoping to use the Storage Access
> API but it requires the user to interact with the embedded app or SiteA.com
> first. However, this isn't possible in this use case because SiteA.com is
> not shown to the user until after they have been authenticated. Is there a
> workaround for this use case?

Hi!

SameSite=none and Secure=true are Chrome initiatives. We are not against them but they have no bearing on default third-party cookie access in Safari.

In Safari you need to use the Storage Access API. The requirement to first get user interaction with the third-party site as first party (in your case SiteA.com) has three reasons:

1) Safari has never accepted cookie set by a third-party resource that doesn't already have cookies. This has been the case since Safari 1.0 2003. A site needs to become first party and set its first cookie(s) as such.

2) When a third-party requests storage access the user will be prompted unless they have already granted this particular third-party cookie access under this first party website. To make sure the user understands what's going on, that third-party will have had to "present itself" as a first party website, with its domain name visible in the URL bar, and gotten user interaction as such.

3) Safari's Intelligent Tracking Prevention feature (ITP) will likely go ahead and delete all website data, including all cookies, for SiteA.com unless SiteA.com has received user interaction as first party website the last 30 days of Safari use. The "likely" part of this is that there is classification of domains going on in the background and being loaded as third-party resource under more than a couple of different websites is enough to get your domain classified. Classified means "has the capability to track the user across websites" and for all such domains that have not received user interaction as first party, ITP will delete all website data.

Hope this helps.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201015/dc6595fa/attachment-0001.htm>