OAuth for Native Apps


This chapter describes some special considerations to keep in mind when supporting OAuth for native apps. Like browser-based apps, native apps can’t maintain a confidential client secret after the developer registers one, as that would require that the developer ship the secret in their binary distribution of the application. It has been proven to be relatively easy to decompile and extract the secret. As such, native apps must use an OAuth flow that does not require a secret.

The current industry best practice is to use the Authorization Flow while omitting the client secret, and to use an external user agent to complete the flow. An external user agent is typically the device’s native browser, (with a separate security domain from the native app,) so that the app cannot access the cookie storage or inspect or modify the page content inside the browser. Since the app can’t reach inside the browser being used in this case, this provides the opportunity for the device to keep users signed in while authorizing different applications, so that they don’t have to enter their credentials each time they authorize a new application.

In recent years, platforms like iOS have been working to further improve the user experience of OAuth for native apps, by providing a native user agent that can be launched from within the application, while still being isolated from the application launching it. The result is that the user no longer needs to leave the application in order to launch a native browser that shares the system cookies. This is known as SFSafariViewController on iOS.

These recommendations for native apps are published as RFC 8252, where these concepts are described in more explicit detail.