Re: [OAUTH-WG] review draft-ietf-oauth-native-apps-07

The Android Account Manager isn't standard OAuth, unlike this BCP.  Thus,
the Account Manager pattern falls under the security considerations section
"Non-Browser External User-Agents" and is officially out of scope of the
specification.

To answer your question though, this BCP *is* the Google recommended way to
do standards-based OAuth on Android. Some official references:

OAuth 2.0 for Mobile & Desktop Apps
<https://developers.google.com/identity/protocols/OAuth2InstalledApp> (which
directly references this BCP! Scroll to the bottom)
Set up SSO with Chrome Custom Tabs with Android for Work
<https://developer.android.com/work/guide.html#sso>
Your Apps at work - Google I/O 2016 <https://youtu.be/Za0OQo8DRM4?t=22m57s>
Modernizing OAuth interactions in Native Apps for Better Usability and
Security
<https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html>

NB. every time you see "AppAuth" in those docs, it's a reference to the
library that implements the pattern defined by this BCP.

The utility of Account Manager really depends on your use-case. I expect
that most people who need to deal with non-Google ASes on Android will
migrate over to the pattern outlined in this BCP.  People who deal
exclusively with the Google IdP (e.g. display a Google Sign-in button) will
likely keep doing what they're doing, which is fine.

The main drawback of the Account Manager pattern was that you need to have
an app from the authorization server (AS) installed which can't always be
guaranteed.  That's why this is less of a problem with Google's IdP, since
all phones that have the Play store come with the Google authentication
agent.

Even if you can guarantee that the authentication app will be installed,
there is overhead on the AS such as maintenance and updates for the native
authorization app component.  I participated in many discussions over a two
year period in the OAuth and OpenID communities, and the general consensus
was that requiring the AS to provide a native app was a burden, and harmful
to interop, which lead to the drafting of this BCP which doesn't require
any native code to be maintained and distributed by the AS.

On Mon, Feb 27, 2017 at 12:22 AM, <Sebastian.Ebling@telekom.de> wrote:

> Hi all,
>
> I have a question that relates to section B.2. Android Implementation
> Details.
>
> I understand this as a working group best practice. Unfortunately this
> does not necessarily meet the Google instruction for Android. There is a
> lot of documentation out there pointing to the Android Account Manager and
> I do not get these both together.
>
> Any idea?
>
> Best Regards
>
> Sebastian
>
> --
> Sebastian Ebling / sebastian.ebling@telekom.de
> Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP)
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>