WebViews are bad — Use AppAuth for Mobile Single Sign-On (SSO)
In a WebView, any malicious code in the page has the same rights as the application. This means you need to make sure to only load trusted content. But there is another risk–a malicious app may also have access to browser content (like cookies) and may snoop passwords or intercept OAuth codes.
So if you download some fun app and it asks you to login somewhere (like Facebook), you may be in trouble. For this reason Google will not let employees use apps that use WebViews to login to Google. And in fact, Google recently announced that in the coming months they will no longer allow OAuth requests to Google in embedded browsers. Read the full announcement.
To counter this risk, new features have been introduced at the mobile operating system level. iOS has introduced SafariViewController for Secure WebViews and Google has introduced Android Custom Tabs.
These components render web pages, but are opaque to the application. The URL is also displayed so you can make sure you are connected to the right page, including the
https certificate information.
At the same time, a new workflow for mobile application security has been developed and documents the best practices for OAuth2 Security. Its a simple, yet innovative design that leverages another innovation in mobile security called RFC 7636: Proof Key for Code Exchange by OAuth Public Clients (PKCE). This introduces an additional secret code that can be sent along with the authorization code request, helping to mitigate the risk of some malicious code running in the browser intercepting the authorization code (without the PKCE secret, the code can’t be exchanged for a token).
The other creative solution introduced by this design is the use of custom URI schemes. Instead of registering
https and the
redirect_uri, the application uses a custom scheme like
myapp:// which enables the browser to securely send the response from the OpenID Provider to the mobile application.
That’s all well and good, but how can mobile developers use this technology without spending hours researching and writing complex client code? Luckily Google has recently released and donated to the OpenID Foundation two open source mobile client libraries that help developers harness the power of this security goodness.
There are currently four OpenID Connect Providers that support AppAuth: Google, Ping, Okta, and Gluu.
One of Gluu’s partners in Finland, Nixu, did some excellent work testing the libraries. Using AppAuth they were able to achieve authentication, SSO between applications, and single logout (although SLO required a patch to AppAuth, adding a
LogoutService class). Ping Identity has also published an AppAuth sample application which is a good reference.
In a recent study of over 600 popular mobile applications, 60% incorrectly implemented OAuth and were thus vulnerable. It’s probably time to review your mobile application security code. And at that time, stop using WebViews for authentication and upgrade existing applications to use AppAuth.
Subscribe to Get News and Product Updates
our RSS Feed