The Pattern
RFC 8252, BCP 212: OAuth 2.0 for Native Apps states that
“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).”
“To conform to this best practice, native apps MUST use an external user-agent to perform OAuth authorization requests.“
Note that URIs can be used by native apps to initiate the authorization request in the device's browser and return the response to the requesting native app.
Note that this also supports the use case when multiple apps use the same AS, so SSO is possible.
External User-Agents
Interesting excerpt from the RFC about external user-agents:
8.7. Fake External User-Agents
The native app that is initiating the authorization request has a
large degree of control over the user interface and can potentially
present a fake external user-agent, that is, an embedded user-agent
made to appear as an external user-agent.When all good actors are using external user-agents, the advantage is
that it is possible for security experts to detect bad actors, as
anyone faking an external user-agent is provably bad. On the other
hand, if good and bad actors alike are using embedded user-agents,
bad actors don't need to fake anything, making them harder to detect.
Once a malicious app is detected, it may be possible to use this
knowledge to blacklist the app's signature in malware scanning
software, take removal action (in the case of apps distributed by app
stores) and other steps to reduce the impact and spread of the
malicious app.Authorization servers can also directly protect against fake external
user-agents by requiring an authentication factor only available to
true external user-agents.Users who are particularly concerned about their security when using
in-app browser tabs may also take the additional step of opening the
request in the full browser from the in-app browser tab and complete
the authorization there, as most implementations of the in-app
browser tab pattern offer such functionality.8.8. Malicious External User-Agents
If a malicious app is able to configure itself as the default handler
for "https" scheme URIs in the operating system, it will be able to
intercept authorization requests that use the default browser and
abuse this position of trust for malicious ends such as phishing the
user.This attack is not confined to OAuth; a malicious app configured in
this way would present a general and ongoing risk to the user beyond
OAuth usage by native apps. Many operating systems mitigate this
issue by requiring an explicit user action to change the default
handler for "http" and "https" scheme URIs.8.12. Embedded User-Agents
[…]
Even when used by trusted apps belonging to the same party as the
authorization server, embedded user-agents violate the principle of
least privilege by having access to more powerful credentials than
they need, potentially increasing the attack surface.Encouraging users to enter credentials in an embedded user-agent
without the usual address bar and visible certificate validation
features that browsers have makes it impossible for the user to know
if they are signing in to the legitimate site; even when they are, it
trains them that it's OK to enter credentials without validating the
site first.
Supported Grants
Apart from the above, it also states that: “Public native app clients MUST implement the Proof Key for Code Exchange (PKCE) extension to OAuth, and authorization servers MUST support PKCE for such clients”.
References
See references also on the parent page.
Apple Developer Documentation - ASWebAuthenticationSession
Apple Developer Documentation - Authenticating a User Through a Web Service
