Different SSO behavior for ASWebAuthenticationSession in iOS 14

I cannot tell exactly what you are running into here without seeing more of the situation, but HSTS does not look like the issue here. Instead you may want to investigate 3rd party cookies as the issue. For example, in the top log are you on domain_a.com and trying to authenticating against and save cookies for domain_b.com? If so you could be experiencing a 3rd party cookie issue here and you would need to use an authentication mechanism like OAuth. If you want to use cookies you would need first party cookies, or cookies from domain_a.com.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Hi! thanks for replying. The domain in both cases ie domaina.com and domainb.com are the same ie: testb2c.b2clogin.com in this case, only the paths are different.

We are using OAuth2 to authenticate against testb2c.b2clogin.com/policya/oauth2/authorize. This gives us a SSO session cookie. Subsequently when I use ASWebAuthenticationSession to authenticate against testb2c.b2clogin.com/policyb/oauth2/authorize , I expected the newly opened safari window to pass the previously obtained session cookie in the request redirects since its the same domain( testb2c.b2clogin.com) but it doesn't do so in iOS 14 and does in iOS 13.

Is the session cookie being considered as a 3rd party cookie? Is there an experimental setting that I can flip to test if the session cookie is being considered as a 3rd party cookie?

The domain in both cases ie domaina.com and domainb.com are the same ie: testb2c.b2clogin.com in this case, only the paths are different.

Thanks for confirming. If you are on testb2c.b2clogin.com and authenticating at a path off of testb2c.b2clogin.com then I would not expect that you are running into a 3rd party cookie issue.

Do you see your server redirecting to the provided Location using the scheme that was given to ASWebAuthenticationSession? Likewise, if you have control over testb2c.b2clogin.com, do you see this authentication request hitting your server?

We are using OAuth2 to authenticate against testb2c.b2clogin.com/policya/oauth2/authorize. This gives us a SSO session cookie

You might want to try running this on the Simulator and capturing the network request flow back and forth from your server using a tool like Charles. If you can see that you are being sent the OAuth token, are able to pick it up in iOS 13, but are unable to do so in iOS 14, then we should get a bug report down for this. If you end up having to open a bug report please follow up with the Feedback ID.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Hi Matt,
I've submitted a feedback item : FB8800086 and attached the trace files when running the app on iOS 13 and iOS 14.

I can see that the request hits the server but without cookie in request header that was set in a previous call for the same domain.

Interesting. Thank you for reporting and submitting the Feedback. I see it internally and have copied myself on it for further info.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

This is fixed in iOS 14.5 beta

@amepatil @meaton

Do we know what fix was made? Or at least to what system?

Is there a mitigation strategy for older iOS 14 versions?

Thanks,
Nikhil

Hello,

Do you have some feedback regarding this fix?

The upgrade to iOS 14.5 fixed the issue for some of our users but not for all of them.

For example, this issue persists with a user with this user-agent: Mozilla/5.0 (iPhone; CPU iPhone OS 14_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1 Mobile/15E148 Safari/604.1.

From the logs I can see that, with ASWebAuthenticationSession, cookies that are correctly set by our server in set-cookie header but are not sent by Safari in the following calls. I precise that we only use first-party cookies.

This concerns a very small number of users but they are completely blocked with no other solution than to reset their iPhone or to buy a new one.

Regards,

The upgrade to iOS 14.5 fixed

Great news!

For example, this issue persists with a user with this user-agent: Mozilla/5.0 (iPhone; CPU iPhone OS 14_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1 Mobile/15E148 Safari/604.1. From the logs I can see that, with ASWebAuthenticationSession, cookies that are correctly set by our server in set-cookie header but are not sent by Safari in the following calls. I precise that we only use first-party cookies.

I'm confused what the User-Agent string has to do with the issue persisting?

Are you able to provide any more information about the non-working case? Have these users not updated to iOS 14.5 yet?

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,

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 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 am facing same issue on iOS 14.6, From a hybrid Cordova app, OIDC authentication URL is opened in SFSafariViewController, up on successfull login session cookie is set by the server. Applicaiton is dismissing SFSVC view and authentication is code is passed to hybrid app for validation. Next time (within few minutes or less that a minute) when SFSafariViewController is opened with OIDC URL, previously set session cookie is missing (Session is needed for a customer context switch case within App for the same logged in user)

This issue is happening for few of the customers only, issues are getting reported as soon as they took 14.6 OS upgrade. Few case were blocked for few days, un-install -> install helped few people, but again it failing for them.

Seems something related to cookie handling in WebKit after 14.6 OS security changes

Having similar issues Raised FB9403191 (Cookie is not sending back on redirect flow)

Having similar issues Raised FB9403191

Thank you for opening a Bug Report, I do see it internally.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com