Impact of iOS 11 no longer providing shared cookies between Safari, Safari View Controller instances

[whitehatguy]

Will AppAuth-iOS continue to use Safari View Controller post iOS 11?

At WWDC, Apple announced a change in the behavior of Safari View Controller with iOS 11 in that stored data (cookies, local storage, etc.) will no longer be shared between instances of Safari View Controller. We've confirmed this in-house with a beta version, and this seems to be independently confirmed by the folks at Branch.

The implication is that using Safari View Controller for OAuth workflows will result in independent instances of authenticated state between each individual application, and could potentially result in an inability for a user to clear such authenticated state (we're still trying to get a handle on this as well with our in-house app dev team - how exactly does one clear cookie state for Safari View Controller post iOS11?)

As a consequence of this, will AppAuth discontinue using Safari View Controller? If so, should developers plan to use guidance offered with what is considered "fall back" today for utilizing Safari directly?

[panva]

Wow, this really blows, how does Apple expect a secure SSO to be achievable now?

[whitehatguy]

From their viewpoint it enables privacy - different apps can allow the user to choose different identities, assuming that the upstream "identity provider" did not already provide the user such capability. From a consumer perspective, it seems to remove the user's choice in this; it also creates the questionable problem as to how the user removes such authenticated state from Safari View Controller.

From an enterprise viewpoint, it seems to eliminate the ability to perform secure single sign-on (without the user having to independently manage authenticated state at each application, or using some other form of "enterprise" authentication such as X509 certificates or Kerberos).

[panva]

... unless the Safari fallback is used straight away, correct? Oh i'm going to have fun explaining this UX bummer to our app stakeholders ;)

[below]

@whitehatguy I can actually see the case for Apple itself: I use different Identities for different developer services, and sso regularly interrupts my flow

[whitehatguy]

@below, I'm not necessarily arguing for or against Apple's behavior - the focus of this issue is primarily the question of what this means for consumers of AppAuth in general. The "contract" of AppAuth-iOS will be markedly different than the behavior of AppAuth-Android and AppAuth-js given this new platform disparity of browser tabs (and disparity between versions of iOS...).

[StevenEWright]

I just wanted to quickly chime in and acknowledge that we are aware of this change as well, that we're keen to hear people's thoughts on this thread, and that we're listening.

[whitehatguy]

@StevenEWright - to share my thoughts/opinions (since you solicited for thoughts above); I'd anticipate that most developers would opt to return to the model of direct Safari integration, except in those rare use cases where a developer both:

• A) Expects the user to use a different identity than the one they would traditionally use on a day-to-day basis
• B) Knows that the upstream identity provider will not permanently store state in Safari View Controller as to prevent later sign-in to the same app with a different identity (I believe this is a problem similar to what people have experienced with Web Authentication Broker in Microsoft's UWP.) I don't immediately have access to the iOS 11 beta API, so I can't necessarily confirm whether they may have added the ability for an app to clear the state of Safari View Controller - in which case, this would be a non-concern.

Since the new behavior of Safari View Controller doesn't match that of Chrome Custom Tab (or simply a secondary browser tab), my personal opinion would be that AppAuth should primarily use Safari directly for parity across platforms (and passivity with the behavior on earlier versions of iOS), with perhaps support for SVC as a secondary platform-specific option.

[madsolar8582]

I have the following radars logged after speaking with Safari engineers at WWDC:
32656250 - Share Data between Safari and Applications (SSO)
32657691 - Allow SFSafariViewController to share data within app groups

[whitehatguy]

It appears that the thought of falling-back to the original OAuth workflow using Safari is a nonsolution. I've seen at least one indication that Apple rejected store submissions that directly used Safari for orchestrating OAuth workflows post-introduction of Safari View Controller.

[ve7jtb]

Yes I have heard that Apple has rejected Apps using the system browser for OAuth.

Some of us are meeting at CIS next week in Chicago, and will review options.

Going back to System Safari seems like the simplest idea but may have risks.

I suspect that dialog with Apple may be required as they have at-least blown up SSO for lots of people.

I think they do have a way for apps to manipulate/clear cookies in the view Controller.

I am hoping that they have some other way to do SSO besides x.509 certs and Kerb that they have just forgotten to mention. Otherwise this will be a mess for folks.

I am speaking tomorrow to the Public Safety Broadband Stakeholders group (FirstNet) and this blows up being able to use iOS devices as forcing someone to log-into each app separately once or twice a day is not going to be a big seller.

John B.

[karlmcguinness-okta]

@ve7jtb seems like apple has an alternative solution proposed in iOS 11 beta 3 SFAuthenticationSession that looks a lot like AppAuth pattern with custom scheme callback. Has anyone has a chance to test this new feature yet?

[panva]

Already in progress as far as i can see => #129

[ve7jtb]

William has a test app. There are still some issues but Apple seems to be accepting them as bugs.

[WilliamDenniss]

#129 with SFAuthenticationSession support has been merged into a new branch ios11beta.

The code is gated on the iOS 11 SDK (thus you can still use it with the iOS 10 SDK and 11 beta SDK at the same time), decided to go for the branch since it's possible the code may break between beta3 and GM. Will merge it to master once the GM is out.

To try it out, update your Podfile to:

pod 'AppAuth', :git => 'https://github.com/openid/AppAuth-iOS.git', :branch => 'ios11beta'

[nyekimov]

XCode 9 GM seed is out, any news on updating the AppAuth?

[DanijelHuis]

Hi, I am testing new iOS 11 code(with SFAuthenticationSession), this is my scenario:

1. My app uses AppAuth to login via IdentityServer, this works OK both on iOS 10 and iOS 11.
2. Users can open webpage from app in SFSafariViewController, this webpage uses same IdentityServer as app. This means that SSO should work, but it doesn't on iOS 11 with new code. It works both on iOS 10 and iOS 11 if I don't use new code.

Do I have to replace SFSafariViewController with SFAuthenticationSession on iOS 11 for SSO to work? It works like that but alert shows each time.
Note that I don't need the SSO to work between SFSafariViewController and external Safari.

Thank you for your work.

[WilliamDenniss]

We had a branch "ios11beta" to try out the changes. I merged this into HEAD yesterday, and have just pushed version 0.90.0, please try it out!

Note that to get the SFAuthenticationSession support you must be using AppAuth >= 0.90.0 with XCode 9.

@DanijelHuis there is nothing that we can do about the alert showing every time. I filed a bug to Apple suggesting they just show this once per app, you could too (the more people they hear from, the more likely they are to consider it).

[Laith-Bzour]

go to OIDExternalUserAgentIOS > line 117 after @available(iOS 13.0, *) write this line : authenticationVC.prefersEphemeralWebBrowserSession = true