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

[Dominick Baier <[e-mail]>]

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