Single Sign-on and iOS 11

Hey Identity Architects, are you aware of the changes coming in Apple's new versions of iOS and macOS? These changes take effect in autumn of 2017 and may affect single sign-on (SSO) user experience in your organization.

The current beta releases of Safari have been enhanced to reduce collusive cross-domain tracking of users. This is being accomplished through additional restrictions on the browser state mechanisms--particularly cookies and the HTML5 local storage mechanisms. Those very mechanisms are relied upon by most organizations to achieve single sign-on.

Single sign-on (SSO), specifically the ability to authenticate once and have that authentication applied to multiple web/mobile applications without requiring additional authentication challenges to the user, is also technically a cross-domain tracking system--just one which the user gets significant value from.

In this article, we'll cover these upcoming changes to Safari and its related services, and specifically how native applications are impacted.

The industry recommendation is that authentication take place via a web-based "identity provider," rather than having applications capture the user credentials itself. This provides many benefits:

1. The application does not have exposure to user credentials.
2. The authentication process can be shared across multiple apps.
3. Authentication can evolve (such as adding support for multi-factor authentication) without requiring additional changes in applications.
4. Applications can be granted partial user access.
5. An application's access can be revoked without requiring a password change or breaking other applications.

Specifications like OAuth 2.0 and OpenID Connect are designed to standardize this process, and to provide for interoperability.

The IETF has also published a list of recommended best practices for security and user experience around use of these specifications in native apps. Sometimes these practices are referred to as the "AppAuth" pattern, after the open-source developer libraries for iOS and Android. The OpenID Foundation hosts and maintains these libraries to support developers in following these best practices when implementing OpenID Connect.

Avoiding use of the embedded browser views for authentication is a major component of these best practices. Unlike the system browser, the embedded browser views allow full control over the browser, including the ability for the application to inject JavaScript, as well as view and modify page content. This level of control enables an application to potentially steal user information or credentials from an embedded browser. Due to this risk, the embedded browser also stays within a sandbox with no access to system-level state or credentials.

In iOS 9, Apple added a new mechanism named SFSafariViewController (SVC). Unlike the older embedded browser functionality, SVC isolated the application from being able to view or control the displayed web content. Since SVC acted as if it was a separate 'tab' of the system browser, the system allowed it access to cookies and provisioned credentials. This resulted in a nicer and more secure user experience.

However, this shared browser across applications can be leveraged to track users and devices without user knowledge or consent, something Apple has historically fought hard to prevent. Apple has designed several new features in iOS 11 to increase privacy and provide better user experience.

The desktop and mobile browsers in macOS and iOS are gaining the capability to sandbox cookies and other local state in a new manner. When a website loads script or other resources from a third-party domain, cookies that are set by those resources might now be "sandboxed" such that they are unique and isolated to that one website. For example, an advertising network attempting to track the user via cookies would no longer be able to do so, as each website using that advertising network would appear as if it was potentially a new browser.

Not all domains are sandboxed in this way. Individual user behavior is used to determine whether the user has an active relationship with the third party, and a third party which the user interacts with may still have a single global version of state.

As user authentication is normally tracked through such cookies, that means each separate service requesting authentication may not appear to your identity provider as if it's a new browser. The heuristics and behavior of this functionality are still potentially fluctuating during beta, so further discussion of this topic will have to wait until iOS 11 is released.

Starting in iOS 11, cookies and other state are no longer shared between an application and the system browser when using SVC. Instead, each application has its own persistent cookie store.

This change allows protocols like OpenID Connect and SAML to continue to function, but impacts the ability to do SSO. Since each application has its own separate cookie store, each will look as if it potentially is hosted on a different mobile device. The resulting user experience is impacted for many applications, as users will need to re-enter their credentials once per application. For sites with longer-lived authentication sessions and sophisticated user behavior analytics, this may cause significant problems.

The initial iOS 11 beta had no obvious alternatives available, which initiated concerns about the negative user experience and security impacts. However, iOS 11 beta 3 added an entirely new mechanism to help with this authentication state issue, named SFAuthenticationSession. This interface is a close cousin of SFSafariViewController, with an even more limited interface and a new consent requirement.

If the user consents to letting the application use a third-party service for signing in, the system will provide a UI for the user with access to system cookies. This user experience behaves similarly to SVC in iOS 10, but now with user knowledge and consent.

The following table is meant to illustrate the various integration alternatives available across iOS releases and their exposed system features:

Mobile Safari appears to be an attractive option with full exposure and great backward compatibility, but historically applications which have attempted to use this integration have had issues during the App Store review process.

In the future, the best practice recommendations are likely to become:

• If the device is running iOS 11, use SFAuthenticationSession.
• If the device is running iOS 9 or 10, use SFSafariViewController.
• If the device is running iOS 8 or earlier (and your application needs to support those users), open the authentication pages in Mobile Safari.

There are still known issues with the current beta implementation of SFAuthenticationSession which would prevent it being a clear-cut recommendation for apps supporting iOS 11. These issues will hopefully be resolved before the production release of iOS 11:

• The consent process appears to be meant to prompt once per IDP and application. However, it is currently prompting the user for consent on each and every use of SFAuthenticationSession.
• There appear to be edge cases around creating new cookies within the system cookie store.

If you've written an application which relies on a library like AppAuth, support for the upcoming changes should only require compiling against a newer version. Initial support for the new SFAuthenticationSession mechanism has already been added to an iOS 11-specific branch.

If your application does not rely on a library meeting best practices, this may be a good time to evaluate whether AppAuth is appropriate for your application.

As always, testing under iOS 11 betas and reporting encountered issues to Apple will help your users have a smooth upgrade experience to the final release.

---------

Stay up-to-date on important identity security news and requirements, subscribe to our weekly blog.