This wiki is no longer active and is left here for historical purposes. Please visit oauth.net for up-to-date information.
View
 

OAuth 2 for Native Apps

This version was saved 7 years, 7 months ago View current version     Page history
Saved by Marius Scurtescu
on June 21, 2010 at 5:39:56 pm
 

Flows

 

While all OAuth 2 flows can be used by native apps, only the user delegation flows will be considered in this document: Web Server, User-Agent and Device flows.

The Web Server and User-Agent flows are similar in that information in the browser must be captured by the native app at some point. Transferring control and information from the browser back to the native app is a hard problem. The next section lists techniques that allow that.

The Device flow does not have the above problem, but it has a potential session fixation vulnerability. Also, this flow is relatively new and it was not used by native apps so it is not proved in practice.

Changes needed by current spec so native apps are supported:

  • Web Server flow
    • define standard result page if redirect_uri is missing
    • make sure unregistered clients are properly supported
    • make sure registered by insecure clients are supported
    • display name parameter may be required
  • User-Agent flow
    • display name parameter may be required
  • Device flow
    • should define standard parameter name for user code
    • display name parameter may be required

 

 

Information Transfer Techniques

 

After the end user approves that the native application gets access to the requested scopes the user-agent is redirected to the redirect_uri. The result page at the redirect_uri should display the information that the native application needs along with instructions for the end user. This information is a verification code (Web Server flow) or access/refresh tokens (User-Agent flow). The information can also include some client state, if it was initially sent by the client.

If the end user denies access, then ideally the result page should also be displayed but the information will be a relevant error code and some explanation for the end user.

The following techniques allow native applications to extract the needed information from the result page.

 

 

Manual copy-and-paste

The result page shows only one piece of text that the end user can copy and then should paste into the native app. Instructions on how to do that should also be provided. The text to be copied could be a single code/token or an encoded data structure.

The authorization dance can happen on a different machine and be controller by a separate web server. The native app could instruct the user to go to a URL and grab an activation code from there. The web application at the URL will start the OAuth dance with the same client Id as used by the native app and at the end show an appropriate result page.

Pros:

  • easy to implement


Cons:

  • loop is not closed automatically
  • user has to copy-paste or memorize-type

 

 

Automatic copy-and-paste

 

The result page uses JavaScript and/or Flash to copy the information to the system clipboard. The native application is watching the clipboard in a loop.

Pros:

  • good user experience


Cons:

  • hard to copy to system clipboard from HTML page, may need flash
  • text copied to clipboard can be seen by other apps, can leak, may need to encrypt
  • native app must ensure it grabs the proper text from clipboard, client state can help
  • requires JavaScript to be enabled in browser to copy to clipboard

 

 

Comments (0)

You don't have permission to comment on this page.