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?
(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.
Thanks for getting back John. So just to clarify, our use case will probably not work correct? By that I mean allowing an iframe to set cookies without user interaction? There is no way to get around the user interaction requirement even if we prompt the user to give us access? I also wanted to bring up something we found during testing. Described below: We created a parent page that contained an iframe with a different domain. We had JS on the iframed child page that would attempt to set a cookie on the document. It was being blocked as expected. We introduced storage access which then prompted the user to accept/deny. We clicked deny. We cleared all cookies/browser history, and started from scratch. We attempted to visit the parent page again and every request for storage access was immediately blocked until we visited the child page in a first party context. Is that expected? It seems like it might be a poor user experience especially if the user accidentally clicked deny.
(In reply to Amol Patel from comment #2) > Thanks for getting back John. So just to clarify, our use case will probably > not work correct? By that I mean allowing an iframe to set cookies without > user interaction? There is no way to get around the user interaction > requirement even if we prompt the user to give us access? First, third-party content, including iframes, have never been able to set cookies under default settings in Safari unless they have “seeded” their cookie jar as first party. Second, your iframe *cannot* prompt the user for storage access unless it has received user interaction as first party the last 30 days of Safari use. Some websites load resources from in the order of a hundred different third-parties. If they were all allowed to prompt the user for storage access, we’d likely end up with an unusable web. The intention of the Storage Access API is to allow for authenticated embeds. This means the user has already logged in to the website as first party and now the embedded content needs access to the authentication state. > I also wanted to bring up something we found during testing. Described below: > > We created a parent page that contained an iframe with a different domain. > We had JS on the iframed child page that would attempt to set a cookie on > the document. It was being blocked as expected. We introduced storage access > which then prompted the user to accept/deny. We clicked deny. We cleared all > cookies/browser history, and started from scratch. We attempted to visit the > parent page again and every request for storage access was immediately > blocked until we visited the child page in a first party context. Is that > expected? It seems like it might be a poor user experience especially if the > user accidentally clicked deny. Clearing browsing history clears cookies and the browsers “memory” of which sites the user has interacted with. This means 1) the user cannot be logged in to the embedee and needs to go to that website and log in, and 2) the requirement to have interacted with the embedee as first party website is no longer fulfilled and thus it cannot request storage access. If the user accidentally clicks deny, they can just try again. The iframe gets two tries as it’s currently implemented. This may change because there are bad actors already misusing the API to pressure users to grant access. All of that is being discussed in the standards GitHub repository since it’s a cross-browser concern.
<rdar://problem/70502017>