We see an increasing demand to use web-based federated login within native non-web applications. SURFnet examined the topic, searching for the right way to do this.
Software Development Kits (SDK)
We looked at different approaches, but in the end only one method per operating system met our requirements. Because we want to really have impact on the way developers implement these methods, we also developed easy-to-use Software Development Kits (SDK) that will enable developers to implement federated login in their applications. In this blogpost we will focus on the investigation and findings while we will look more closely to the SDK’s in a later blogpost.
No generic solution
SURFnet and many other NREN’s are using web based protocols such as SAML 2.0 for their authentication and authorisation platforms. Although this makes for a great and secure user experience on the web, it is difficult to apply this method to native non-web applications since these are typically designed for an operating system and often do not support federated login.
Because there is no generic cross-operating system solution available, developers implement various workarounds such as embedded browsers and application-specific credentials. These methods are undesirable from a security point of view or due to usability.
Secure and multi-platform
We held all methods for web-based authentication against the same requirements. The most important ones from a security point of view are that users can see the web address and validate the SSL-certificate, and that the credentials cannot be hijacked and remain at the Identity Provider.
To ensure compatibility with modern devices, a selection of commonly used, future proof and/or popular versions of desktop and mobile operating systems was made:
- Microsoft Windows 7, 8(.1), 10, RT and Phone
- Apple OS X 10.9+, iOS 8 and iOS 9.
- Android 2.2+
Most methods are insufficient
We found that each operating system provides quite similar methods. For example webview and browser redirect are commonly used methods which only differ slightly between operating systems. In addition Microsoft and Apple provide developers with specialised methods such as Microsoft’s WebAuthenticationBroker class and Apple’s Safari View Controller on iOS 9.
Practically all of the methods involving webview have proven to be insecure and inadequate because of security issues and the absence of an address bar. The same is true for Microsoft’s WebAuthenticationBroker class, which in addition also saves user credentials in the cloud.
The right way
This in contrast with the more or less similar Safari View Controller in iOS 9, which shows the address bar with certificate to users and normally saves user credentials locally. One drawback of Safari View Controller is that it is only available on iOS 9.
Browser redirection can be used on all operating systems but Apple iOS and proved to be the more reliable and secure method. Because the default web browser is used, the user has full access to the address bar and the browser’s functionality. Unfortunately, this also makes the user flow less smooth than when using webview because the user must switch to another application (the web browser). However, we feel that this solution offers a good balance between security and usability.
Browser redirection and Safari View Controller
We concluded that browser redirection (Windows, Android and OS X) and Safari View Controller (iOS) are the best methods to use. With this in mind, we have built the aforementioned Software Development Kits that we will discuss further in the next blog.
Read the full report Federated Login to Native Applications (PDF). If you have any questions, please contact Sebas Veeke (firstname.lastname@example.org).