Re: [OAUTH-WG] popular apps that use appauth?

[Vittorio Bertocci <[e-mail]>]

The callbacks do avoid the loopback, which is great, but the usability
remains harder than mobile and the embedded case: the auth tab appears
among others, the modal windows remain a possibility, etc - the level of
sophistication of the target audience of the github app can definitely
(hopefully?) navigate those challenges, but for consumer grade apps they
can be blockers. When decision makers are presented with concrete support
costs from customer calls vs possible security issues, it's often hard to
make a case for the latter.

[image: image.png]

On Mon, Feb 25, 2019 at 3:40 AM Dominick Baier <[e-mail]>
wrote:

> A good example of a desktop application using browser authentication is
> Github for Desktop.
>
> They use custom URLs/callbacks for both OSX and Windows. Works very well.
>
> ———
> Dominick
>
> On 25. February 2019 at 11:48:20, Vittorio Bertocci (
> vittorio=[e-mail]) wrote:
>
> Ahh, as John knows this is a big pet peeve for me :)
>
> Although that's all true on mobile, on desktop things are more
> complicated.
>
>    - Using a system browser on the desktop (Linux/Mac/Windows) means that
>    you don't control the experience (there might be modal dialogs occluding
>    the browser or any other Z order windows factors; the browser instance
>    might have already other tabs open; the default browser of any particular
>    machine can be different; users might need to take steps to get back to the
>    app; etc)
>    - Use of loopback adapters is banned by many big enterprises on their
>    machines
>    - The big security advantages of the approach on mobile, where apps
>    are all nicely sandboxed, is not as pronounced in an environment where the
>    user login session in the machine is the main security boundary (think
>    keylogger attaching to the main windows events pump, or a debugger - all
>    stuff not possible on mobile but viable on desktops)
>
> True, it would be fantastic if desktop OSes would offer system browser
> features comparable to what's available on iOS and Android - but today that
> doesn't appear to be the case. And the inability to leverage existing
> sessions when using embedded views on the desktop is a true pain. But
> judging from the behavior of the most popular desktop apps in market
> (Office, Slack, Adobe Reader, Visual Studio, even the Google Drive app for
> Mac...) losing the ability to access cookies is less of a nuisance for
> users than all of the above. And considering that desktop machines usually
> have their own way of identifying devices, that is also not much of a
> factor for desktop apps.
>
> The best practice has been discussed for the last 4 years and still all of
> the big apps above remain on embedded: it is however telling that the
> mobile apps from the same vendors all embraced the system browser approach.
> Since the native best practices came out, I have been working with desktop
> developers dealing with this cognitive dissonance of the best practice
> saying something that is very hard to put in practice. I understand that it
> is well intentioned and it is easier to give one single advice for both
> mobile and desktop, but while the necessary features and experiences are
> lacking on the desktop I am not sure how much of a difference it is making
> in that use case.
>
>
>
> On Mon, Feb 25, 2019 at 12:59 AM David Waite <[e-mail]>
> wrote:
>
>>
>> > On Feb 24, 2019, at 10:43 AM, William Denniss <wdenniss=
>> [e-mail]> wrote:
>> >
>> > For 1P sign-in, there are several good reasons to go with
>> ASWebAuthenticationSession, like syncing the signed-in session with Safari
>> and using it if it already exists.
>>
>> With enterprise 3P, you’ll have to use some web agent for authentication
>> pretty much no matter what, and you’ll almost certainly get pressure to use
>> ASWebAuthenticationSession, and/or potentially lose deals to competitors
>> during product evaluations. It is simply what is required for robust
>> integration into a corporate infrastructure.
>>
>> For 1P on iOS, it depends on the complexity of authentication for first
>> party. If you are just doing password and maybe SMS-based challenges, there
>> is decent enough native app integration for password sharing and SMS
>> keyboard for that to keep conversions high, even with having to
>> authenticate twice.
>>
>> However, if you want to authenticate the device (even pseudonymously with
>> session cookies) or do other factors, the authentication is simpler with
>> ASWebAuthenticationSession. Which means your life will be easier if you
>> have more complex authentication requirements anywhere on your roadmap to
>> just start off using ASWebAuthenticationSession.
>>
>> It is likely that future authentication technologies like WebAuthn will
>> not work with an embedded web view. The ability to arbitrarily inject
>> javascript means that apps can phish webauthn responses for domains via
>> embedded web views.
>>
>> -DW
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>