Hi William, Thank you very much for your very detailed response!
May be I was a bit gruff. I simply expected best practices about Android Account Manager vs. native OAuth in the Android Implementation Details section. I did not realize, that it is addressed by “Non-Browser External User-Agents” within the security considerations. Nevertheless, I highly appreciate this BCP document and also the work that has been done in behind to improve browser integration in Android and iOS. Best regards Sebastian -- Sebastian Ebling / sebastian.ebl...@telekom.de / +49 6151 5838207<tel:+4961516807135> Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP) Von: William Denniss [mailto:wdenn...@google.com] Gesendet: Freitag, 3. März 2017 03:13 An: Ebling, Sebastian Cc: oauth@ietf.org<mailto:oauth@ietf.org> Betreff: 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.ebl...@telekom.de<mailto:sebastian.ebl...@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.ebl...@telekom.de<mailto:sebastian.ebl...@telekom.de> Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP) _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
