This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
OAuth 2.0 for Native Apps
OAuth 2.0 for Native Apps

Version management

Difference between version and

At line 1 added 41 lines
!!! 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']
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop