Getting Started with OAuth 2.0

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 ...