Bringing Single Sign-On to Mobile Applications

July 1, 2015

At the recent CIS conference in San Diego, I hosted a session on Bringing Single Sign-on to Mobile Applications. I hope you find this summary of the session useful. If you are interested in watching the session, you can access it here.


We have had single sign-on across Web based enterprise applications for many years. It is a feature that most users just expect to work.


They provide their credentials once and have access to many applications both internal to the enterprise as well as ones provided by third parties like SalesForce and Workday.


As workers transitioned to mobile devices, the expectation was that the experience would be similar.


Unfortunately what happened was that each app became its own island of identity. Users were forced into authenticating in each application, often to the same backend server.


What went wrong?


When OAuth and OpenID Connect were designed, the specifications required the applications to use the system browser for authentication. That did two things, it prevented the native app from being able to capture the user's credentials, and it allowed the authorization server to use cookies to share the user's authenticated session across multiple native apps.


The problem was that the apps developers turned out to be more concerned with what looks good in their app, and not considering the user's need for multiple applications.


This caused them to use the OS recommended feature of using an "Embedded Web View" to show the web content and avoid having their app suspended by invoking the system browser.


The downside of this approach is that each "Web View" is sandboxed, preventing the sharing of cookies, certificates, and HTML5 local storage.


A number of workarounds have been tried such as sharing access tokens between applications using the system keychain, however that only works if all the applications are signed by the same developer. That didn't work for SaaS apps or third party enterprise apps.


Other approaches involved creating MDM containers for all the apps abut that required applications to be wrapped in special API and increased developer overhead.


The OpenID Foundation formed a work group (NAAPS) to address the problem, and try to create a standardized solution that could work across multiple platforms.


That work resulted in an IETF specification called "Proof Key for Code Exchange" (PKCE), that addressed some of the security issues with using custom scheme URI. The NAAPS WG explored a number of workarounds using a Token Agent app that could maintain the user's login state with the IdP on behalf of a number of applications.


As a result of a significant amount of work and lobbying, both Apple and Google have just announced similar changes to Android and iOS that will enable applications to use a "Custom Chrome Tab" on Android or a "Safari View Controller" on iOS 9. These both enable sharing session cookies and allowing auto fill for passwords that are unavailable in the older methods. The new browser views also protect the user from having their password intercepted by the application. Additionally the browser view has a back button that returns the user to the application if they don't want to sign-in.


This is the user experience that the OAuth and OpenID Connect authors were originally hoping for.


Most of the problems we have been working around to get single sign-on working for native applications have now been addressed by the two major mobile OS vendors (Microsoft has a plan for Windows 10, but it is different, as you might expect).


The NAAPS WG is going to continue to document best practices for Single Sign-on for Enterprise and Software as a Service Providers using these new features in combination with the PKCE specification, as well as filling in any remaining gaps to allow SaaS providers to fully support OAuth and OpenID Connect enabled native applications in a secure way without forcing users into extra unproductive logins.


Stay tuned!