!!! Overview[1]
[{$pagename}] ([BCP 212]) is an [RFC Sub-series] [Best Current Practice] ([BCP]) and uses the [AppAuth] [SDK].


[Section 9|https://tools.ietf.org/html/rfc8252#section-9|target='_blank'] of the [OAuth 2.0] Authorization Framework [RFC 6749] documents two approaches for [native applications] to interact with the [Authorization_endpoint]: 
* an [embedded user-agent] 
* an [external User-Agent]

This [Best Current Practice] requires that only [external User-Agents] like the [browser] are used for [OAuth] by [native applications].  [{$pagename}] 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.

This practice is also known as the "AppAuth pattern", in reference to [open Source] libraries [AppAuth] that implement it.

[OAuth Public|OAuth Public Client] [native applications] [clients|OAuth Public Client] [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|https://tools.ietf.org/html/rfc8252#section-8.1|target='_blank'].

!! 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.  

They involve the user [Authentication] with their full login [credentials], only to have them downscoped to less powerful [OAuth 2.0] [credentials]. (Remember [OAuth 2.0 NOT an Authentication protocol])

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.

[{$pagename}] document recommends [External User-Agents] like [Chrome Custom Tabs] or [SFSafariViewController] as the only secure and usable choice for [OAuth 2.0]

[OAuth 2.0 Protocol Flows] between a [Native application] and the system browser (or another external [user-agent]) are:
* more secure
* take advantage of the shared [authentication] state to enable [Single Sign-On].

Inter-process communication, such as [OAuth 2.0 Protocol Flows] between a [Native applications]  and the system [browser|user-agent] 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.

[{$pagename}] also documents:
* Using [Custom URI schemes] for Redirection
* Authorization servers [SHOULD] support [Loopback URI Redirection] on the loopback IP address and [HTTP] scheme

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [AppAuth|https://appauth.io/ |target='_blank']