Over a million developers have joined DZone.

OAuth 2.0 Best Practices for Native Apps

DZone's Guide to

OAuth 2.0 Best Practices for Native Apps

Using OAuth 2.0 for your native apps' authentication and authorization? Here are the best practices you need to keep in mind.

· Security Zone ·
Free Resource

Mobile is increasingly becoming a part of every consumers’ identity, but the increasing use of this digital channel is escalating the security risks faced by consumers and institutions.

In October 2017, the Internet Engineering Task Force (IETF) released the Best Current Practices (BCP) when using OAuth 2.0 with native mobile applications. This BCP states that OAuth 2.0 authorization requests from native apps should only be made through external user agents, primarily the user's browser. We'll discuss what this means for developers and users and any security considerations involved.

OAuth 2.0 Best Current Practice for Native Apps

The IETF (Internet Engineering Task Force) recently released the Best Current Practice for OAuth 2.0 for Native Apps Request For Comments. This document requires that, in accordance with best practices, only external user agents (such as the browser) should be used with the OAuth 2.0 Authorization Framework by native applications; this is known as the "AppAuth pattern". Embedded user agents should not be implemented.

For authorizing users in native apps, the best current practice is to perform the OAuth authorization request in an external user agent (typically the browser) rather than an embedded user agent (such as one implemented with web-views).

-OAuth 2.0 for Native Apps

Using the browser to make native app authorization requests results in better security. It also enables use of the user's current authentication state, making single sign-on possible. Embedded user agents are unsafe for third parties. If used, the app has access to the OAuth authorization grant as well as the user's credentials, leaving this data vulnerable to recording or malicious use. Embedded user agents also don't share authentication state, meaning no single sign-on benefits can be conferred.

We'll go into the security and implementation advantages of using the browser for authorization requests in more detail below.

Authorization Flow for Native Apps Using the Browser

The authorization flow for native apps using the browser acts as illustrated in the following diagram:

Authorization flow for OAuth 2.0 in native apps using the browser

  1. Client app opens a browser tab with the authorization request.
  2. Authorization endpoint receives the authorization request, authenticates the user, and obtains authorization. Authenticating the user may involve chaining to other authentication systems.
  3. Authorization server issues an authorization code to the redirect URI.
  4. Client receives the authorization code from the redirect URI.
  5. Client app presents the authorization code at the token endpoint.
  6. Token endpoint validates the authorization code and issues the tokens requested.

Figure 1, OAuth 2.0 for Native Apps

URIs are used for OAuth 2.0 on the web for authorization requests and responses. Similarly, URIs can also be used in native apps. When the built-in browser is employed by the user for all native app logins, certain advantages are conferred, such as the ability to use a single sign-on session stored in a central location and additional security afforded by an authentication context that is separated from the app. Browser security is also a major focus of vendors, and they tend to manage security and sessions policies quite well. In addition, supporting and implementing the same approach in web and native apps reduces complexity and increases interoperability.

Initiating and Receiving Authorization Requests

Native apps now must request user authorization by creating a URI with the appropriate grant type specified in the OAuth 2.0 Authorization Framework. The app then redirects the user to this request URI. A redirect URI that the native app can receive and parse appropriately must also be supplied. This must be implemented using an external user agent. Use of the device browser is recommended.

The authorization server must permit at least three redirect URI options for the response sent back to the native app:

  • Private-Use URI Scheme Redirection
  • Claimed "https" Scheme URI Redirection
  • Loopback Interface Redirection

You can read about these three options in detail in Section 7 of OAuth 2.0 for Native Apps.

OAuth 2.0 Security Considerations for Native Apps

When implementing OAuth 2.0, there are a number of security considerations that developers must be mindful of when using best current practice with an external user agent. We'll go over a few of them now.

Authorization Code and Grant Flow

Using the redirect options above means that the authorization code can only be received by native apps on the same device. While this increases security, it does still mean that another app on the same device could potentially intercept the code. The Proof Key for Code Exchange (PKCE) protocol was created to defend against this attack vector. Public apps as well as servers must use PKCE, and servers should reject authorization requests from apps that do not.

It is not recommended to implement implicit grant flow in native apps because this flow cannot be protected by PKCE. Instead, authorization code grant flow with PKCE should be used.

Authorization Servers and Clients

In most cases, native apps are considered public clients and must be registered with the authorization server. Authorization servers must also register a client's complete redirect URI. If an authorization request does not match the registered redirect URI, the request must be rejected.

User authentication and consent will be required by the authorization server, as per any other web browser based OAuth 2.0 flows.

User Agents

Embedded user agents should not be used to masquerade as an external user agent. Authorization servers can protect against these fake agents by requiring an authentication factor only available to genuine external user agents.

Cross-Site Request Forgery (CSRF) attacks should also be mitigated by using the state parameter to link client requests and responses. More details are available in section 5.3.5 of OAuth 2.0 Threat Model and Security Considerations.

The user's browser is the recommended external user agent. Embedded user agents must not be used for authorization requests. Authorization servers may detect and block requests from embedded user agents, as they are unsafe for third parties, such as the authorization server itself. The reason for this is because the app can then access not only the OAuth authorization grant, but also the user's full authentication credentials. The app could then potentially record or use this information maliciously. In addition, embedded user agents don't share authentication state with other apps or the browser and therefore disabling single sign-on benefits.


If you're a native app developer, it's very important to adhere to best current practices. Please take the time to read over the OAuth 2.0 for Native Apps RFC yourself. Using an external user agent for OAuth 2.0 authorization requests provides better security as well as an improved user experience as it enables single sign-on across the device's apps and browser.

Explore the authentication advancements that are designed to secure accounts and payments—without overburdening consumers with a friction-laden experience.

native apps ,security ,mobile app secuirty ,best practices

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}