[Webkit-unassigned] [Bug 210298] New: [ITP] Cross Domain SSO cookies not sent in Safari 13.1/STP 104
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Apr 9 13:12:22 PDT 2020
https://bugs.webkit.org/show_bug.cgi?id=210298
Bug ID: 210298
Summary: [ITP] Cross Domain SSO cookies not sent in Safari
13.1/STP 104
Product: WebKit
Version: Safari 13
Hardware: Macintosh
OS: macOS 10.15
Status: NEW
Severity: Major
Priority: P2
Component: Frames
Assignee: webkit-unassigned at lists.webkit.org
Reporter: dtychshenko at gmail.com
CC: wilander at apple.com
Created attachment 395994
--> https://bugs.webkit.org/attachment.cgi?id=395994&action=review
Simple application diagram
First of all, my apologies for a long post. I'm a noob to ITP and can't figure out a problem that is most likely due to my misunderstanding of its rules.
With the release of Safari 13.1 our application's SSO broke, and I've spent the last week reading webkit blog, webkit bugzilla and various other channels. I'm stuck and have nowhere else to reach for help, so I really appreciate any advice in advance!
## Details
Our main application is hosted on mainapp.example.ca and contains an iframe hosted on subframe.example.ca. The iframe needs to be able to call services on both *.example.ca and *.example.com domains.
First, a user logs into the main application on mainapp.example.ca. The application authenticates against an SSO endpoint hosted on sso.example.ca, which returns an authentication cookie like: `Set-Cookie: auth=...; path=/; domain=.example.ca; secure; samesite=none; HttpOnly`.
The browser is then sent to sso.example.com/copy which copies the authentication cookie from .ca to .com domain: `Set-Cookie: auth=...; path=/; domain=.example.com; secure; samesite=none; HttpOnly` and responds with a 302 redirect back to the main application.
Now the user is logged in and inside the application, they reach a page which has an iframe hosted on subframe.example.ca that makes several network calls to various endpoints on api.example.ca and api.example.com domains.
I see that the calls to api.example.ca has authentication cookie, but api.example.com doesn't, so they fail. The cookie used to pass through in Safari <= 13.0.5, and also works fine in Chrome and Firefox, but starting with Safari 13.1 it stopped working. If I disable ITP through Experimental features, everything works as expected in Safari 13.1
After finding the [recent blog post on webkit.org](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/) regarding full third party cookie blocking in Safari 13.1, I started looking into the Storage Access API, but not getting anywhere with it. I've tried calling it from the top frame and from the inner iframe and not able to get access or a popup asking me for access:
`document.hasStorageAccess()` called from the top frame always resolves to `true`.
`document.requestStorageAccess()` called from the top frame always resolves without a popup.
`document.hasStorageAccess()` called within the subframe always resolve to `false`.
`document.requestStorageAccess()` called within the subframe always rejects without value and without a popup.
I've tried adding an explicit user gesture. I've added a button within the iframe that triggers the above methods before any network calls are made but still got the same results.
I've read that a redirect is not enough for ITP, so I tried to explicitly interacting with the SSO sites and manually logging in on sso.example.com, as well as sso.example.ca, before I login on the main application, but the results are still the same.
Each time I try something new I make sure to Clear all history and restart Safari before I do anything.
ITP debug mode is not providing much information. I only see the same message over and over again:
```
2020-04-09 11:22:13.779214-0400 0xeca56 Info 0x0 57786 0 com.apple.WebKit.Networking: (WebKit) [com.apple.WebKit:ITPDebug] Done updating cookie blocking.
2020-04-09 11:22:15.340601-0400 0xeca55 Info 0x0 57786 0 com.apple.WebKit.Networking: (WebKit) [com.apple.WebKit:ITPDebug] Done updating cookie blocking.
2020-04-09 11:22:19.444489-0400 0xeca58 Info 0x0 57786 0 com.apple.WebKit.Networking: (WebKit) [com.apple.WebKit:ITPDebug] Done updating cookie blocking.
```
Starting with Safari Technology Preview 104 I see a couple of more additional logs related to the redirect:
```
2020-04-08 17:17:56.151289-0400 0x9ca43 Info 0x0 80926 0 com.apple.WebKit.Networking: (WebKit) [com.apple.WebKit:ITPDebug] Did set example.ca as making a top frame redirect to example.com.
2020-04-08 17:17:56.416058-0400 0x9ce0f Info 0x0 80926 0 com.apple.WebKit.Networking: (WebKit) [com.apple.WebKit:ITPDebug] Did set example.com as making a top frame redirect to example.ca.
```
Based on this I thought maybe ITP was blocking because of the top frame redirect, so as a test I've removed the redirect altogether, but still get the same results.
Luckily, I'm able to run our iframed application standalone on a top frame to test things. Even better, as a test, I can also run it on both, subframe.example.com and subframe.example.ca domains, which allowed me to simplify the flow as much a possible. I was able to remove the main application and remove the redirects out of the picture altogether to try to isolate the problem, but still didn't get anywhere.
I have tried different SameSite cookie settings too. I've tried None, Lax and not setting SameSite at all with no difference.
## Simplified case (TLDR)
The simplest case that I was able to get to:
1. Clean all history, restart Safari
2. in a new browser window go to sso.example.ca and login => .example.ca cookies are set
3. go to and login at sso.example.com => .example.com cookies are set
4. go to subframe.example.ca in browser (top frame) => AJAX calls to api.example.ca succeed (has cookies), but calls to api.example.com fail (no cookies)
5. go to subframe.example.com in browser => AJAX calls to api.example.com succeed (has cookies), but calls to api.example.ca fail (no cookies)
## requestStorageAccess rules
I've reviewed all the Storage Access API rules:
- `If the sub frame is sandboxed but doesn’t have the tokens “allow-storage-access-by-user-activation” and “allow-same-origin”, reject.`
✅The iframe is not sandboxed
- `If the sub frame’s parent is not the top frame, reject.`
✅The sub frame's parent mainapp.example.ca is the top frame, while subframe.example.ca iframe is the direct child of mainapp.example.ca
- `If the browser is not processing a user gesture, reject.`
✅I've tried adding a button on subframe.example.ca within the subframe and triggering the requestStorageAccess() call in the click handler of that button to have an explicit user gesture, but saw no change in behavior: hasStorageAccess() resolves with false, requestStorageAccess() rejects without value and no popup from the browser asking me to grant access.
- `If the sub frames eTLD+1 is equal to the top frame’s eTLD+1, resolve.`
✅Subframe at subframe.example.ca is on the same eTLD+1 as the top frame on mainapp.example.ca
- `If the sub frame’s origin’s cookies are currently blocked, reject. This means that ITP has either purged the origin’s website data or will do so in the near future. Thus there is no storage to get access to.`
❓I have no way of telling if or why the cookies have been purged. I know that the browser does have both sets of cookies because calls to .com services work from .com site and calls to .ca services work from .ca site.
- `If all the above has passed, resolve.`
❌Does not resolve
## Browsers tested
✅Chrome 80 works
✅Firefox 75 works
✅Safari 13.0.5 works
❌Safari 13.1 doesn't work
❌Safari Technology Preview 104 doesn't work
Any help would be greatly appreciated!
--
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/20200409/9e33c264/attachment-0001.htm>
More information about the webkit-unassigned
mailing list