Mobile OS Developments and Native Application Authentication

June 19, 2015

At its recent WWDC, Apple announced some IoS 9 features that will likely be important for the authentication and authorization of native applications. Coincidentally, Google announced similar features for the upcoming Android M at I/O two weeks earlier.


One new feature common to both OSs is, on the surface of it, *merely* a UI change. Both Apple's SFSafariViewController and Android's Chrome Custom Tabs introduce a third choice for presentation of web content. Whereas in the past developers could choose to display web pages in either the system browser or as a webview embedded directly into their application UI, these new mechanisms provide a middle ground - one without the jarring UX of leaving the app completely (as is the case for the system browser) but still able to access shared state of the main browser such as session cookies.


For native applications using OAuth, the best practice require the user authenticate and authorize access via a web page hosted by the Authorization Server (AS). These new web views promise to be an important middle ground for native application authentication - providing a compromise between the system and embedded browsers.


Some application developers, rejecting the disruptive UX of using the system browser for the authentication and authorization step, chose to embed the web view - effectively hiding from the user that they were actually on a web page when logging in and giving their authorization. But, while arguably optimal from a UX point of view, embedded web views have a number of significant drawbacks for authentication purposes.


First, any password submitted through a form in such an embedded web view may be accessible to the code of the application surrounding the web view. This is not much of an issue when the app itself is developed by the same entity to which the user is authenticating, but this is not always the case; e.g., consumer apps using Google for login, or SaaS apps relying on federated SSO from the enterprise. Second, these embedded web views do not have the same privileges with respect to accessing resources as do the system browsers - notably in this context, embedded web views cannot access X.509 certificates provisioned down the to phone for authentication purposes. Third, because two different webviews cannot share session state with each other, it is not easy to provide a single sign-on (SSO) experience for users across multiple applications.


These new features from Apple and Android address both the UX concerns (the windows are modal, and when closed, the user returns to the application) of using the system browser for authentication, and the security issues (they can share state and access to system resources with the system browser) of relying on embedded web views.


A separate (but complementary) feature coming to both Android M and iOS 9 is an improvement on how native applications can link between themselves, and their associated web servers. Both Android's App links and Apple's Universal Links allow application developers to claim an association with a particular web domain. Once claimed, any http(s) addresses to that domain will be interpreted by the OS as belonging to that application and not the default system browser. Similar to the previous custom URL schemes used for inter-app messaging, the new linking mechanism promises to close the security issue associated with custom URLs, namely how it was possible for other applications to squat on the URLs of a given app, and so gain access to the data shared by those URLs. By requiring that an app developer, in order to lay claim to a particular domain, be able to demonstrate ownership of that domain by placing a specific file on that domain, the new link mechanisms will shut out the hackers.


Again, in the context of a native application getting the user authenticated against an OAuth AS, the new linking mechanisms promise to provide additional assurance that the tokens are being issued to a valid application, and not some malicious application that was able to get itself installed and squatting on the valid custom scheme URLs. (The Proof Key for Code Exchange (PKCE) mechanism was motivated by the same risk, though PKCE allows the AS to ensure only that the tokens were returned to the particular application that requested them, which could be a bad app).


The Native Applications (NAPPS) WG in the OIDF is in the process of discussing the impact of these new mobile OS features on the emerging NAPPS spec. Apple's Universal Linking and Android's App Links both appear to provide a meaningful security enhancement and so it may make sense for NAPPS to stipulate their use. The SFSafariViewController and Chrome Custom Tabs, by providing what appears to be a reasonable balance between UX and security, can enable a SSO experience for users across different native applications, without the introduction of a specialized Token Agent (TA), as NAPPS defines. In this model, the browser, with its session cookies now accessible by the new web views, logically plays the role of a TA. The NAPPS WG will be exploring how this 'browser-only' model for native SSO either eliminates the value of, or possibly complements, a native TA. One scenario is that a TA would lay claim to the OAuth AS authorization endpoints so that, when installed on a device, the TA would facilitate native application authentication. If no TA were present, the AS address would be handled by the browser as normal.