The (Ugly) Web Browser
Many mobile application developers have objected to using OAuth for their native applications because it requires either embedding a WebView or opening up the system web browser on the device. They don’t view either of these as good options, as a web browser often feels different than a native UI.
This is a reasonable concern, though we always need to balance security and usability. We should expect that the user experience for these OAuth browser-based flows will continue to improve along with increased pervasiveness of HTML5 technology and mobile web UX design techniques.
Embedded WebView
The embedded WebView has become a popular way to handle OAuth
authorization grants for native mobile applications. Instead of opening
up the system web browser (via an Intent
on Android or UIApplication
on iOS), the embedded WebView
simply includes a browser within the main application window. This
mechanism leads to a smaller context switch for the user, while at the
same time providing the native app greater control over the web
browser.
Primary advantage
WebViews are easily controlled by the native application. This enables the application to easily access the OAuth access token or authorization code by examining the cookie store or the title of the application window, without worrying about the issues of registering a custom URL scheme.
Some disadvantages
WebViews don’t display the trust indicators present in the system web browser (such as the SSL/TLS lock indicating certificate ...
Get Getting Started with OAuth 2.0 now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.