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

[Aaron Parecki <[e-mail]>]

Please remember that not having this draft will not stop people from
building native login experiences into apps.

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.

> 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.

> 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. 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.

Aaron

On Tue, Sep 10, 2024 at 6:47 AM Neil Madden <[e-mail]> wrote:

> Yes, I’ve watched the recordings. I have sat through many client meetings
> where UI designers insist that a “native experience” is absolutely
> essential, despite the clear security problems with it. But that native
> experience is normally actually worse for users, despite appearing to look
> better (eg no automatic SSO from existing web browser cookies etc). I’m yet
> to hear a genuine argument in favour of the “native experience” that
> doesn’t boil down to aesthetic preferences.
>
> Limiting the endpoints to first party apps, via some strong client
> authentication method (attestation) helps with some of the security
> concerns, but it doesn’t really address the root issues. If we encourage
> users to enter credentials directly into apps, then phishing apps become a
> danger, exactly as RFC 8252 says (regarding in-app user-agents, but the
> same principles apply):
>
> "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.”
>
>
> s/embedded user-agent/native UI/ and I think this argument very much applies to the current draft.
>
>
> Even if you lock down the API so those other apps cannot login directly
> with those credentials, it is too late if the user has already entered
> their username and password. Use of a native UI, which is easily spoofed,
> bypasses all of the phishing protections that browsers have added over the
> years (eg warning about malicious sites, highlighting the origin, password
> manager origin checking before auto-filling, etc).
>
> Secondly, 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
> seems to run contrary to AIB statements like
> https://datatracker.ietf.org/doc/statement-iab-statement-on-the-risks-of-attestation-of-software-and-hardware-on-the-open-internet/ (a
> draft, admittedly).
>
> — Neil
>
> On 10 Sep 2024, at 13:55, Aaron Parecki <[e-mail]> wrote:
>
> Neil, I don't know if you've seen the several presentations I did at the
> last few IETF meetings about this work, but a large part of the motivation
> of this work is because *currently* people are bending over backwards to
> provide a native user experience for their first party apps and doing so in
> a way that is not only not standard, but even worse than what could be done
> with a standardized method. Please go review those recordings for more of
> the background.
>
> I am open to the discussion of how best to limit this to first party apps,
> maybe that part needs to be stricter than what is currently in the draft.
> But at the very least, the draft says in no unclear terms that this is not
> for use by third party apps.
>
> Aaron
>
>
> On Tue, Sep 10, 2024 at 3:59 AM Neil Madden <[e-mail]>
> wrote:
>
>> I know that apps that accept credentials directly are common place. But
>> the direction of travel has so far been to discourage that: eg deprecating
>> ROPC, requiring use of an external vs embedded user-agent etc. (Sorry, I
>> misremembered: it’s BCP 212 that requires this, not the security BCP — and
>> it has a lot of good rationale for that decision).
>>
>> 3rd party apps follow where first-party apps lead.
>>
>> — Neil
>>
>> On 10 Sep 2024, at 11:14, Dick Hardt <[e-mail]> wrote:
>>
>> 
>>
>> Neil
>>
>> Users input credentials directly into apps all the time in OAuth -- it is
>> at the AS.
>>
>> There are many deployments that use OAuth where the AS and RS are the
>> same party. The objective of this draft (as I understand it) is to provide
>> a simplified OAuth flow for this use case. The BCP does not address this
>> use case.
>>
>> Why would we not want to provide a best practice for deployments where
>> the AS and RS are the same party? We will likely improve the security of
>> those deployments over them making up their own protocol, won't we?
>>
>> /Dick
>>
>>
>>
>> On Tue, Sep 10, 2024 at 10:20 AM Neil Madden <[e-mail]>
>> wrote:
>>
>>> The draft is motivated by allowing native apps to provide a login
>>> journey for OAuth rather than using the browser. This encourages people to
>>> input credentials directly into apps, which (a) directly contradicts the
>>> advice in the security BCP, and (b) opens up users to significantly more
>>> attack vectors (including that the phishing-resistance of FIDO is
>>> significantly weakened). We shouldn’t be encouraging this.
>>>
>>> — Neil
>>>
>>> On 5 Sep 2024, at 15:48, Tim Cappalli <[e-mail]> wrote:
>>>
>>> 
>>> IMO, we're getting very off topic here. The WebAuthn text is not part of
>>> the draft being called for adoption.
>>>
>>> On Thu, Sep 5, 2024 at 2:15 AM Neil Madden <[e-mail]>
>>> wrote:
>>>
>>>> On 5 Sep 2024, at 05:45, David Waite <[e-mail]>
>>>> wrote:
>>>> >
>>>> > 
>>>> >
>>>> >> On Sep 4, 2024, at 4:27 PM, Neil Madden <[e-mail]>
>>>> wrote:
>>>> >>
>>>> >>> On 4 Sep 2024, at 22:48, Watson Ladd <[e-mail]> wrote:
>>>> >>>
>>>> >>> I can always grab the cookie jar off the user browser if I have that
>>>> >>> level of access.
>>>> >>
>>>> >> USB access is not privileged, but that’s beside the point.
>>>> >
>>>> >>
>>>> >> Put another way, the phishing-resistance of WebAuthn only really
>>>> makes sense in a world of sandboxed apps: web apps, mobile apps. Any spec
>>>> that encourages the use of OAuth auth flows outside of such sandboxed
>>>> environments, as this one potentially does, is going to make defending
>>>> against phishing harder.
>>>> >
>>>> > The client is not an identified/authenticated component in the
>>>> architecture, so there is a user trust required in using a client - that
>>>> the client actually is an agent acting in the user’s interest rather than
>>>> acting maliciously.
>>>> >
>>>> > Platforms have the ability to provide specific API for these
>>>> interactions to become a trustworthy client, and to block privileged access
>>>> (including access to speak directly to hardware) behind audited
>>>> entitlements to prevent from installed software acting as a malicious
>>>> client.
>>>>
>>>> Right, this is what I mean by sandboxed.
>>>>
>>>> >
>>>> > Note that some platforms also provide entitlements and heuristics for
>>>> password manager access - however, as a knowledge-based system the platform
>>>> cannot really prevent malicious applications from still attempting to
>>>> manipulate their way to credential phishing.
>>>> >
>>>> >>
>>>> >> (I’d also question why first-party apps need a standardised API for
>>>> this anyway: they can do whatever they like using proprietary APIs already).
>>>> >
>>>> > I would struggle to come up with standards-track RFCs which would not
>>>> be able to instead be accomplished with proprietary APIs. The editors and
>>>> working groups found value in peer review and in interoperability.
>>>>
>>>> Standards are for promoting interoperability, not for getting free peer
>>>> review of private APIs.
>>>>
>>>> >
>>>> > I have seen the pitfalls of a proprietary approach to this and would
>>>> say peer review is important. My primary concern is whether we can have a
>>>> clients that authenticate against multiple implementing ASes based solely
>>>> on this work. Profiling authentication methods like passkey-based
>>>> authentication would go a long way toward alleviating that concern.
>>>> >
>>>> > -DW
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>> _______________________________________________
>>> OAuth mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>> _______________________________________________
>> OAuth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>
>