This Best Current Practice requires that only external User-Agents like the browser are used for OAuth by native applications. OAuth 2.0 for Native Apps documents how native applications can implement authorization flows using the browser as the preferred external User-Agent as well as the requirements for Authorization Servers to support such usage.
OAuth Public native applications clients MUST implement the Proof Key for Code Exchange by OAuth Public Clients (PKCE RFC 7636) extension to OAuth, and authorization Servers MUST support PKCE for such OAuth Public Client, for the reasons detailed in Section 8.1.
Summary #At the time of writing, many native applications are still using WebViews, a type of embedded user-agent, for OAuth 2.0. These embedded user-agents are however unsafe for use by third-parties by definition.
The WebView approach has multiple drawbacks, including:
- the client Application being able to be an eavesdropper on user's credentials
- is a suboptimal user experience as the authentication session can't be shared (ie no Single Sign-On)
- Authentication must be performed to each Application separately.
Inter-process communication, such as OAuth 2.0 Protocol Flows between a Native applications and the system browser can be achieved through URI-based communication. As this is exactly how OAuth works for web-based OAuth flows between OAuth Client and Identity Provider (IDP) websites, OAuth can be used for Native application auth with very little modification.
OAuth 2.0 for Native Apps also documents:
- Using Custom URI schemes for Redirection
- Authorization servers SHOULD support Loopback URI Redirection on the loopback IP address and HTTP scheme