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

From: "Brock Allen" <[email-masked]>
Date: Sat, 23 Feb 2019 17:05:12 +0000

I often have push back from customers (mainly the marketing department/UX folks) when suggesting AppAuth for native/mobile apps (IOW RFC8252). They ask for examples of any other popular or well known apps that follow this practice. Does anyone on this list have examples?

TIA

-Brock

---

From: Dominick Baier <[email-masked]>
Date: Sun, 24 Feb 2019 00:26:12 -0800

The Uber app uses it for their OAuth flow to PayPal e.g.

———
Dominick

On 23. February 2019 at 18:05:33, Brock Allen ([email-masked]) wrote:

I often have push back from customers (mainly the marketing department/UX
folks) when suggesting AppAuth for native/mobile apps (IOW RFC8252). They
ask for examples of any other popular or well known apps that follow this
practice. Does anyone on this list have examples?

TIA

-Brock

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: David Waite <[email-masked]>
Date: Sun, 24 Feb 2019 02:29:27 -0700

Offhand, Google Apps on iOS. Also the Facebook SDK uses a similar pattern. 

I believe third party apps which use Google for SSO are mandated to use it as well. Slack and Pokémon Go, for examples. 

A few apps will also use it or a similar pattern (for SAML) once they have determined it is an enterprise account. Some businesses are pushing hard for the others to change - a lot of EMM solutions and other authentication methods (like mutual TLS) don’t work properly with embedded browser views. 

-DW

> On Feb 24, 2019, at 1:26 AM, Dominick Baier <[email-masked]> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Sun, 24 Feb 2019 12:11:44 -0300

I have been told that YouTube and other Google apps on iOS use the 
AppAuth flow.  I don't know if they use the AppAuth SDK or just follow 
the pattern.

Interestingly I was told that switching to AppAuth increased login 
conversions for them with YouTube.   That was a while ago.

John B.

On 2/24/2019 5:26 AM, Dominick Baier wrote:
> On 23. February 2019 at 18:05:33, Brock Allen ([email-masked] 
> <mailto:[email-masked]>) wrote:
>
>> I often have push back from customers (mainly the marketing 
>> department/UX folks) when suggesting AppAuth for native/mobile apps 
>> (IOW RFC8252). They ask for examples of any other popular or well 
>> known apps that follow this practice. Does anyone on this list have 
>> examples?
>>
>> TIA
>>
>> -Brock
>>
>> [email-masked] <mailto:[email-masked]>

---

From: "Brock Allen" <[email-masked]>
Date: Sun, 24 Feb 2019 15:32:34 +0000

> Interestingly I was told that switching to AppAuth increased login conversions for them with YouTube. That was a while ago.

I think you just said the magic words that marketing folks like to hear. Thanks all.

-Brock

---

From: William Denniss <[email-masked]>
Date: Sun, 24 Feb 2019 09:43:31 -0800

For apps signing-in third party (3P) users on iOS, Google Sign-in does require
<https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html>it
(for 2.5 years & counting now), I'm also noticing it all over the place in
other apps for 3P sign-in as it's really the only viable option for 3P
sign-in - which is the argument we make in RFC 8252.

First party (1P) sign-in is an interesting case, since for 1P there are
more options available. Google apps do use the ASWebAuthenticationSession
for 1P user sign-in, simply go "Add another account" in an app like Maps to
try. I've noticed a few other apps doing this of late as well, such as
Target which uses SFSVC for sign-in of their own 1P users, which I assume
was implemented before ASWebAuthenticationSession existed.

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.

---

From: David Waite <[email-masked]>
Date: Sun, 24 Feb 2019 17:59:37 -0700

> On Feb 24, 2019, at 10:43 AM, William Denniss <wdenniss=[email-masked]> 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

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 25 Feb 2019 10:47:51 +0000

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 <[email-masked]>
wrote:

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

---

From: John Bradley <[email-masked]>
Date: Mon, 25 Feb 2019 08:21:25 -0300

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=
[email-masked]> wrote:

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

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 25 Feb 2019 03:38:37 -0800

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 <[email-masked]> wrote:

>>    - 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)
>> 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
>> 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 <
>> [email-masked]> wrote:
>>
>>>
>>> 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.
>>>

---

From: Dominick Baier <[email-masked]>
Date: Mon, 25 Feb 2019 03:40:22 -0800

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=[email-masked]) wrote:

Although that's all true on mobile, on desktop things are more
complicated.

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 25 Feb 2019 03:40:39 -0800

I wish I could edit emails. Fixing some meaning changing typos.

Regardless of what the future might look like, the problems I listed above
are concrete blockers for the adoption of that pattern on 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
known issues and not something they are doing wrong.

On Mon, Feb 25, 2019 at 3:38 AM Vittorio Bertocci <[email-masked]>
wrote:

>>>    - Use of loopback adapters is banned by many big enterprises on
>>>    their machines
>>>> 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.
>>>>

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 25 Feb 2019 03:56:09 -0800

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.

---

From: John Bradley <[email-masked]>
Date: Mon, 25 Feb 2019 10:28:53 -0300

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.

---

From: David Waite <[email-masked]>
Date: Mon, 25 Feb 2019 17:57:17 -0700

> On Feb 25, 2019, at 4:56 AM, Vittorio Bertocci <[email-masked]> wrote:
> 
> 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.

True, but these were all a reality when AppAuth first came about as well - the fall-back was custom URL schemes through the system browser, which meant an application switch, a new tab, a possible modal prompt to get the user back to the application, etc.

It is a harder problem on desktop operating systems because it is more challenging to decide if “external user-agent” always means “system browser” or “user default web browser”, and if the latter that means a testing matrix to understand the UX and limitations. Hypothetically, in some enterprises external user-agent might even mean “this security product we bought”.

However, we will see more mandatory sandboxing and hard-to-obtain entitlements necessary to talk to the resources we want for authentication. If you are only doing 1P authentication you have a longer runway than a company who wants to leverage third party or enterprise-deployed authentication. And to optimize the UX, those applications may have a period where they decide to include both AppAuth and non-AppAuth flows.

-DW