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

[John Bradley <[e-mail]>]

Win 10 2019H1 has a WebAuthn API for third party apps.   Chrome and Fire
Fox are now using it.

Trusted browsers have some whitelisting involved.   Other apps will be able
to use the API eventually.  There are some issues around the RPID for apps
and websites that may make the authentication broker simpler.

Android has a API but it requires whitelisting and really only talks to the
platform authenticator at the moment.

So for the moment AppAuth is the best option for WebAuthn.

John B.


On Mon, Feb 25, 2019, 8:38 AM Vittorio Bertocci <[e-mail]> wrote:

> True, the WAB is perhaps the best approximation of a desktop system
> browser-like feature, but it doesn't solve Mac or Linux. Even within the
> Windows world, Win10 usage pulled ahead of Win7 only in January, and
> barely- and the WAB isn't available on Win7.
> In fact, you bring up an excellent point. I am wondering if the OS vendors
> are making any plans to make WebauthN available to desktop apps beyond 1st
> party applications.
>
> Regadless of what the future might look like, the problems I listed above
> are concrete blockers for the adption of that pattern on that desktop. I am
> wondering if those issues should be explicitly acknowledged in the best
> practices document, so that developers running into them realize they are
> now issues and not something they are doing wrong.
>
> On Mon, Feb 25, 2019 at 3:21 AM John Bradley <[e-mail]> wrote:
>
>> On Windows Web Authentication broker is a option.
>>
>>
>> https://docs.microsoft.com/en-us/uwp/api/Windows.Security.Authentication.Web
>>
>> I have encouraged Apple to provide a SSO service on OSX.
>>
>> The availability of WebAuthn in browsers may make the platforms rethink
>> some things.
>>
>> John B.
>>
>>
>> On Mon, Feb 25, 2019, 7:48 AM 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
>>>
>>