Oauth_2.0 - Getting Access to User Data from Mobile Apps

There are two main classes of mobile applications: mobile-optimized web apps using HTML5 and other web technologies and native mobile applications. While mobileoptimized web apps can use the traditional OAuth client-side or Web Application flows with some special consideration for user experience, native mobile applications require additional considerations.

Why You Should Use OAuth for Native Mobile Apps

When building a native mobile app, there are two primary reasons you should consider using OAuth:

Access to your own APIs
Many mobile applications have backend servers that they use to keep track of user data. Perhaps your app is a game and stores high scores and level completion data in a server-side database to enable social functionality or supporting playing the game on multiple platforms. In this case, your app needs to communicate with the backend using an API, typically a REST-based HTTP API. OAuth is a great way to handle API authorization for these types of applications, and it enables you to build and maintain only one interface for users to log in to your application, whether they’re on the Web or using your native mobile companion app.

Access to APIs from other providers
Some API providers may require you to use OAuth for API authorization. However, for those that don’t, there are still several great reasons you want to use OAuth for native mobile apps: you have an obligation to help users stay safe and also a desire to make your application easy to use by all users. Asking users for their password for third-party services reinforces this pattern and makes users more vulnerable to phishing attempts. This further requires that your app have access to the user’s entire account (as opposed to a limited scope of data) and requires your app to store the user’s credentials on the device for long-lived access, potentially leaving them open to compromise. Another primary reason that you want to consider using OAuth is that some users at specific API providers may simply not be able to delegate access to your app with a typical username and password because they use a second-factor authentication scheme (such as a one-time password key token) or their account is federated to another identity provider (via OpenID, SAML, etc.).

What Flow Should Be Used for Native Mobile Apps?

The available flows for native mobile apps will likely be restricted based on what flows are supported by your API provider. However, there are a few questions you can consider when deciding what flow to use.

Do You Have a Mobile Backend Web Server for Your Application?

Yes: If you have a mobile backend web server for your native app, you can use one of the typical OAuth flows for web applications: the client-side (implicit) flow or the flow for server-side web apps. The same considerations apply: Do you need long-lived “offline” access from your mobile app’s backend server? Use the server-side web app flow. Or do you need short-lived one-time access directly from the native app? Use the clientside implicit flow.

When using the server-side web app flow and passing an authorization code to your server, the user of the app will still need to be authenticated to the app backend, similar to how a user is authenticated to web application servers using session cookies. No: If your application does not have a mobile backend web server powering it, you need to use some type of native application flow. This can be very similar to the serverside web app flow or the client-side implicit flow, but there are two restrictions: you don’t have a web server to use for the redirect_uri, and you should maintain the confidentiality of any client_secret values, which are sometimes required for the server-side flow.

Depending on the mobile platform you’re building on and the API provider you’re using, you can use a custom URI scheme such as my-mobile-app://oauth/callback for the redirect_uri in order to return the authorization code or access_token to your application. However, on some platforms, these custom URI schemes can be registered by multiple applications (and their uniqueness is not guaranteed), so there is a risk that the tokens could be intercepted by the wrong app on the device and used maliciously. It’s also possible that your API provider requires preregistration of these redirect_uri values and does not accept values using custom URI schemes.

There are also some API providers supporting a native client flow. With the native client flow, a special redirect_uri value is used to send the authorization code or access token to a web page hosted by the OAuth authorization server. The user can then copy/paste this value into the application or the application can programmatically grab the value from the body or window title and close the web browser window.

The currently proposed special redirect_uri value for the native client flow is urn:ietf:wg:oauth:2.0:oob. Figure 6-1 shows an example result web page after the user approves access to their data. In most cases, the user would never see this page, however, because the application would grab the access token and close the window before it is visible.


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 chain validation and the URL of the site). Users may be prompted to enter their credentials to log in to the OAuth authorization provider. This results in users being more vulnerable to phishing attacks if evil apps are deployed onto user devices.
• With separate cookie and history stores, the user is not logged into any accounts. This means that they must login to the OAuth Authorization Server before granting access to an app, and entering credentials on mobile devices can sometimes be a painful experience.
  
  System Web Browser
  
  Opening up the system web browser seems like the natural way to send a user through an OAuth grant flow, but as with the embedded WebView, there are both advantages and disadvantages to this technique.
  
  Some advantages
• The system web browser uses the system cookie store. If your application integrates with a popular API provider, it’s likely that the user is already logged into the provider—resulting in a simple single-click grant process. Users don’t need to retype their password.
• Users have greater security assurances with the system web browser, as they’re accustomed to the typical security indicators (such as the SSL/TLS lock and the URL of the site). This makes users less vulnerable to phishing. Some disadvantages
• Using the system web browser requires that the user be returned to the native app after granting access. As mentioned above, this typically done using a custom URI scheme such as my-mobile-app://oauth/callback for the redirect_uri. Because there is no central registry of these custom schemes, other malicious applications installed on the device may be able to intercept the OAuth access tokens or authorization codes.
• The history store of the system web browser cannot be controlled by the native app, leading to potential compromise of OAuth access tokens if the implicit flow is used. While this is also a problem on desktop web browsers, it’s more of a concern with mobile devices, which are more portable and thus more susceptible to loss and theft. This risk is usually mitigated by the short validity of OAuth access tokens.

Enhanced Mobile App Authorization for Specific Providers

Some OAuth providers have built special mobile libraries or applications to make doing OAuth easier on devices and to improve the user experience.

For Google

On its Android operating system, Google provides a service called the AccountManager. Originally this service was designed to allow applications to request auth tokens for Google APIs using the proprietary ClientLogin mechanism. However, this service has been updated to support getting OAuth 2.0 access tokens for Google APIs.

In order to get an OAuth 2.0 access token, you simply need to call AccountMan ager.getAuthToken() to request a token using an authTokenType of oauth2:. For example, to request access to the Google Tasks API, specify an authTokenType of oauth2:https://www.googleapis.com/auth/tasks. Unfortunately, this literal string will be presented to users when they’re asked to grant access, so using this technique is not recommended. However, for some APIs, such as Google Tasks, there are aliases such as Manage Your Tasks that can be used in place of the oauth2: value to produce a much friendlier request.

After you call getAuthToken(), the account manager will ask the user to approve or deny the request using a native application prompt. If the user approves the request, the application will be issued an access_token value, which can be used in API requests. The Google Tasks API team has created an article with more details on using this technique. Although other Google APIs may not have user-friendly aliases such as Manage Your Tasks, the general techniques described in the article will still apply.

Google does not have similar functionality available for iOS at the time of this writing. However, Google does have a client library for Objective-C which makes creating an embedded WebView OAuth flow very easy to implement on iOS.

For Facebook

Facebook has SDKs available for both Android and iOS that automatically prompt the user for requested permissions.

On Android, you call Facebook.authorize() and wait for the user to approve the authorization request. After the user approves, you can call Facebook.getAccessToken() to get an access token for use with the requested APIs.

« Previous | 1 | 2 | 3 | Next »

---

---