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:
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.
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:
Cons:
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:
Cons:
The native app registers a custom URI scheme that will launch the application itself, or a helper app. The redirect_uri would use this scheme.
Pros:
Cons:
The native app starts a local web server on some available port and the redirect_uri will point to this server.
Pros:
Cons:
The native app embeds a browser.
Pros:
Cons:
The native app watches the cookie jar of the browser it launched. The result page will save the information to a cookie using JavaScript.
Pros:
Cons:
The native application launches a browser and then keeps tracking the process and the corresponding OS window title. The result page should make sure the information shows up in the window title.
Pros:
Cons:
The native app relies on a browser extension it can communicate with. The extension notices when the result page is rendered, extracts the information and passes it to the native app.
Pros:
Cons:
|
Web Server | User-Agent |
Manual copy-paste | Yes | No1 |
Automatic copy-paste | Yes | Yes2 |
Custom Scheme | Yes | Yes |
Local Server | Yes | Yes |
Embedded Browser | Yes | Yes |
Monitor Cookie | Yes | Yes2 |
Monitor Title | Yes | No3 |
Extension | Yes | Yes |
Notes:
|
GUI Desktop | CLI Desktop | Smart Phone |
Manual copy-paste | Yes | Yes | No1 |
Automatic copy-paste | Yes | Yes | ? |
Custom Scheme | Yes | Yes | Yes2 |
Local Server | Yes | Yes | No |
Embedded Browser | Yes | No | Yes |
Monitor Cookie | Yes | Yes | ? |
Monitor Title | Yes | Yes | No |
Extension | Yes | Yes | No |
Notes: