In 2016 I wrote RFC 8252 seeking to codify a new best practice on using the system browser (or in-app browser tabs) to perform OAuth flows, rather than a built-in WebView.
A little history: you don’t see this embedded WebView OAuth pattern much any more, but when I joined the Identity team at Google in 2014, it was everywhere, and there was a popular OSS client library which helped developers do it this way. With the WebView pattern, the user would login to their identity provider in a view inside the app during the OAuth flow (as documented in section 9 of RFC 6749). This had some problems including security (the containing app can take the session authentication token, which is typically more privileged than the OAuth token), and usability (the user has to login again every time), a full list of issues can be found in section 8.12 of RFC 8252. My work on 8252 was to codify a new approach by using the system browser. As for that old client library? Together with my colleagues, I created a better one to provide a reference implementation of 8252. In 2016, Google formally required developers to adopt this modern approach for better security and usability.
So, WebView for OAuth is bad. But what does this mean for “in-app browsers” that under the covers use WebView? Apps like Firefox which are branded as a browser, but also social apps that essentially contain a browser when you open a link (we can debate what “browser” means, but at a minimum it’s something that lets you navigate the web, and displays a URL bar). What happens if an OAuth or sign-in flow were to happen in such an in-app browser, not for the purposes of getting the native app an oAuth token, but rather as part of the user’s natural flow while browsing the web?
Note: what follows is my personal opinion in my individual capacity as the author of RFC 8252. It does not represent a policy or opinion of my employer.
I think it’s worth clarifying here that the issue RFC 8252 seeked to address was primarily the embedded OAuth flow within a native app. The policy was not intended to apply to browser applications that use WebView as implementation detail. Browser applications have a high level of trust already; users trust the browser with their session tokens for every site they use. By “browser application”, I’m including apps that don’t market themselves as a browser, but nevertheless contain what is essentially a browser experience when you navigate to a link.
What sets an “in-app browser” apart from an “embedded WebView OAuth flow” is that at the end of the OAuth flow, the containing native app is getting an OAuth token (and hopefully discarding the session cookie), whereas with an in-app browser, the user is gaining a signed-in state to the identity provider which is intended to persist in that in-app browser’s cookie jar, like any other browser. For example, if the user opens a link to a news site in an in-app browser, and then tap a “Sign-in with provider” link, it’s the web site, and not the native app that is receiving the OAuth token, so the RFC 8252 best practice does not apply here. This experience is like any other web browser based OAuth flow, that just happens to occur in an app that is hosting the browser.
I personally consider the pattern of every app including their own custom browser a bit of a UX anti-pattern (as a user, I prefer links to open in the main browser where all my logged in sessions are), but personal views aside I think the correct treatment for OAuth providers is to consider the experience within an in-app browser like any other browsers. Browsers require high-trust, so this definitely isn’t a pattern that random apps should implement (and I think identity providers are well within their rights to block low-reputation browser apps), but high-trust social apps used by millions of people likely pass that bar.