Overview[1]#
OAuth 2.0 for Native Apps (BCP 212) is an RFC Sub-series Best Current Practice (BCP) and uses the AppAuth SDK.Section 9
of the OAuth 2.0 Authorization Framework RFC 6749 documents two approaches for native applications to interact with the Authorization_endpoint:
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.
This practice is also known as the "AppAuth pattern", in reference to open Source libraries AppAuth that implement it.
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.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.
OAuth 2.0 for Native Apps 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 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
More Information#
There might be more information for this subject on one of the following:- BCP 212
- Claimed Https Scheme URI Redirection
- Embedded user-agent
- IOS.URIScheme
- Internet User Authorization
- Loopback Interface Redirection
- Native application
- OAuth 2.0 Client Registration
- OAuth 2.0 Device Authorization Grant
- Private-Use URI Scheme Redirection
- RFC 8252
- Web Blog_blogentry_071017_1
