ASWebAuthenticationSession cookie

Any update on this issue? Was anybody able to resolve it? A similar issue on Safari gets resolved by unchecking Prevent cross-site tracking. We could see cookies shared in request. But on native mac client using WKWebview, there is no way we can do it.

Safari by default discards cookies set in an iframe unless the host that's serving the iframe has set a cookie before, outside the iframe. Safari is the only browser that does this.

Hello, I'm still not getting the name and email from Sign in Flow. My application is implemented in .Net Core 3.1 using the OpenIdConnect. I've specified the scopes as following but when getting the code and idtoken, not user data is added. .AddOpenIdConnect(Apple, async options => { options.Scope.Clear(); options.Scope.Add(name); options.Scope.Add(email); ... } .. options.Events.OnAuthorizationCodeReceived = async context => { // no user object within the idtoken } The authentication cookie is generated but can't proceed with new account creation. I'm also using the ExternalLogin structure OnGetCallbackAsync. The url seems to have all required info as explained in this ticket. Is someone facing same issue? Thanks

We eventually resolved this by launching out to Safari instead of using webviews inside our app. Per this link: https://developer.apple.com/app-store/user-privacy-and-data-use/ If tracking occurs within a webview inside an app, do I need to use the AppTrackingTransparency prompt? Yes. If you are using a webview for app functionality, it should be treated the same way as native functionality in your app, unless you are enabling the user to navigate the open web. So if you plan on using a webview to display the content inside your app, and that content uses cookies, you will need to display the ATT popup or you will be rejected. We switched to launching out to Safari instead of keeping them in-app, and we were promptly approved, no need for ATT since our app was no longer able to track the user across sites or apps. Hope that helps.

Hello meaton, I'm working with loula on the same project. The cookies are set on the same domain, so we are not using any third party cookies. This issue is happening in a completely hazardous way so we are not able to reproduce it on our devices. Moreover, we cannot provide an instruments trace since it's affecting our clients (end-users). How can we proceed in this case please ? Regards

I'm having same issue. Any idea if WKWebview support third party cookie or any way to enable it?

thanks so much for your input! So when you talk about bugs are investigated for URLSession and WKWebView I can assume that those APIs are expected to honor NSPinnedDomains? URLSession, yes. WKWebView, I do not know. Last I knew this point was being investigated by that team. Regarding: What about ASWebAuthenticationSession or SFSafariViewController? Should NSPinnedDomains be honored here theoretically? At least in my testing, I was not able to make it work for SFSafariViewController so I even didn't bother to try for ASWebAuthenticationSession I do not have an answer here either. The best recommendation I can provide is if WKWebView is determined to work then I would try NSPinnedDomains with ASWebAuthenticationSession and SFSafariViewController also. If this is not determined to work then I would file Enhancement Requests for these APIs to work with NSPinnedDomains. Matt Eaton DTS Engineering, CoreOS meaton3@apple.com

Hi Matt, thanks so much for your input! So when you talk about bugs are investigated for URLSession and WKWebView I can assume that those APIs are expected to honor NSPinnedDomains and Apple eventually will provide fixes, right? What about ASWebAuthenticationSession or SFSafariViewController? Should NSPinnedDomains be honored here theoretically? At least in my testing, I was not able to make it work for SFSafariViewController so I even didn't bother to try for ASWebAuthenticationSession

When calling the authorization endpoint, after redirection, the cookie is not sent to the authentication server by Safari. The cookie header is empty. If you have an Instruments Trace of this action or a Charles Log I would add it to a bug report. This may be expected if you are relying on third party cookies during your redirect workflow, but the fact that it is working inconsistently sounds like it's grounds for a bug report. Matt Eaton DTS Engineering, CoreOS meaton3@apple.com

Hello, Thanks for your response. The upgrade to iOS 14.5 fixed the issue only for some users. Not for all of them. I specified the user-agent just to show you that the user who still experience this issue has upgraded to iOS 14.5. Here are the details regarding the circumstances in which the problem occurs: An in-app browser tab is opened (ASWebAuthenticationSession) to let the user login to our application (OIDC flow) The user authenticates and the authentication server redirects him/her (with a 302) to the authorization endpoint with a set-cookie header containing the session cookies (set-cookie: session=xxxxxxxxxx; path=/; expires=Thu, 20 June 2021 20:25:45 GMT; samesite=none; secure; httponly) When calling the authorization endpoint, after redirection, the cookie is not sent to the authentication server by Safari. The cookie header is empty. What is strange is that this only affects some iOS users on different versions including 14.5 ... Regards,