[OAUTH-WG] Re: Call for adoption - First Party Apps

[Neil Madden <[e-mail]>]

> On 10 Sep 2024, at 16:43, Aaron Parecki <[e-mail]> wrote:
> 
> Please remember that not having this draft will not stop people from building native login experiences into apps.

That is not a good reason to standardise it!


> This is particularly a problem for companies that build authorization server products that are used by people building apps, since the result is then that they end up building proprietary APIs for building native login experiences, and if these companies are large enough it turns in to a de-facto standard anyway.

Given that I spent a long time at ForgeRock, working on their AS implementation, I am familiar with this. FR’s own implementation of this API was inherited from its authentication framework that came from Sun’s OpenSSO (and Sun/Netscape’s iPlanet before that). This was in turn based on Java’s JAAS framework, with its system of callbacks (NameCallback, PasswordCallback etc). This is effectively a technology-agnostic way to prompt for various credentials and identifiers. But given that OAuth is the *Web* Authorization Protocol, we already have a nice way to describe these requirements: HTML. And we have this lovely framework where any app can popup the system browser to handle all that for you in a consistent way, with shared cookies (with approval), and so on. That all works right now.

> 
> > I’m yet to hear a genuine argument in favour of the “native experience” that doesn’t boil down to aesthetic preferences.
> 
> "aesthetic preferences", also known as "user experience", is absolutely a valid concern for many people.

Actually, no these aren’t the same. The aesthetic preferences that dominate these discussions of those of the UI designers and product managers, which is often focused on looks and branding and keeping users within the app. The UX is often objectively worse in a “native experience”: inconsistent across different apps, no SSO, etc.

> 
> > locking down the API to first-party apps only sets a precedent that eg the official BlueSky/Twitter/Facebook app will always have a different/privileged login experience compared to third-party apps
> 
> This has very much been in line with the goals of OAuth from the beginning, giving third-party apps a different experience from first-party apps. I don't see this as a problem.

Yikes! From my POV it was precisely to allow third-party apps to have safe access to the *same* APIs that first-party apps used. It was because, when there wasn’t a safe way to do this, apps instead directly asked for the user’s username and password and then did it anyway.

> This is also becoming more relevant with the prevalence of the pattern of using a first-party native app *as* the authorization server for other native apps on the device. (e.g. a health tracker app wants to get access to your Strava data, it starts an OAuth flow to the Strava native app, where the user has to log in and approve the request. It would be very weird for the Strava app to then do a web OAuth flow to the Strava website. Instead, I have seen a number of apps that build out the authorization approval screen in the native app, so there is never even a browser involved in the third party OAuth flow at all.)
> 
> Also please note that the current draft never mentions passwords as an authentication mechanism. The first example given is passkey login, which as Tim mentioned earlier in this thread is phishing-resistant on mobile devices since it's handled by the operating system rather than the app.

Sure, but what is passkey adoption now? Are there any good stats? The reality is that most apps now and for quite some time in the future will be using passwords, OTPs and other phishable credentials.

— Neil