[OAUTH-WG] Pushing "OAuth 2.0 for Native Apps" to the IESG -- Short Working Group Last Call

[Hannes Tschofenig]

Hi all,

after the working group last call of the "OAuth 2.0 for Native Apps"
document July last year (see
https://www.ietf.org/mail-archive/web/oauth/current/msg16534.html) I
had, as a shepherd, collected IPR confirmations (see
https://www.ietf.org/mail-archive/web/oauth/current/msg16672.html) and
produced a shepherd writeup (see
https://www.ietf.org/mail-archive/web/oauth/current/msg16702.html).

Since version -03 and the current version -07 a fair amount of text has
been changed, see
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-oauth-native-apps-03.txt&url2=https://tools.ietf.org/id/draft-ietf-oauth-native-apps-07.txt

Although most of those changes are editorial and normative changes have
been discussed on the mailing list I believe it is fair to let the group
take a brief look at the final version.

For this reason we will issue a short, one week, working group last call
before pushing the document to the IESG.

So, please provide your comments to the list no later than February 27th.

Here is the link to the document again:
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07

Ciao
Hannes & Derek

[S***@telekom.de]

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 / ***@telekom.de
Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP)

[William Denniss]

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

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.

Post by Hannes Tschofenig
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
--
Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP)
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[S***@telekom.de]

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 / ***@telekom.de / [phone]<tel:[phone]>
Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP)



Von: William Denniss [mailto:***@google.com]
Gesendet: Freitag, 3. MÀrz 2017 03:13
An: Ebling, Sebastian
Cc: ***@ietf.org<mailto:***@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 http://youtu.be/Za0OQo8DRM4
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, <***@telekom.de<mailto:***@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 / ***@telekom.de<mailto:***@telekom.de>
Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP)



_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

[S***@telekom.de]

Hi,

there is a typo in B.4.
Search for "are are" and replace it with "are".

Best regards

Sebastian

[Brian Campbell]

-07 LGTM

Post by Hannes Tschofenig
Hi all,
after the working group last call of the "OAuth 2.0 for Native Apps"
document July last year (see
https://www.ietf.org/mail-archive/web/oauth/current/msg16534.html) I
had, as a shepherd, collected IPR confirmations (see
https://www.ietf.org/mail-archive/web/oauth/current/msg16672.html) and
produced a shepherd writeup (see
https://www.ietf.org/mail-archive/web/oauth/current/msg16702.html).
Since version -03 and the current version -07 a fair amount of text has
been changed, see
https://tools.ietf.org/rfcdiff?url1=https://tools.
//tools.ietf.org/id/draft-ietf-oauth-native-apps-07.txt
Although most of those changes are editorial and normative changes have
been discussed on the mailing list I believe it is fair to let the group
take a brief look at the final version.
For this reason we will issue a short, one week, working group last call
before pushing the document to the IESG.
So, please provide your comments to the list no later than February 27th.
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07
Ciao
Hannes & Derek
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Nat Sakimura]

It looks generally good. Thanks William and John for creating it.

I spotted a few nits.

NS1: MUST is not a recommendation
================================
In 8.5, it says:

(which is a recommended in Section 7.1.1
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07#section-7.1.1>)

However, in 7.1.1, it is a MUST, i.e., required instead of recommended. So,
"recommended" in the above sentence needs to be changed to "required".


NS2: Dynamically registered client can be treated as a confidential client
=======================================================
In 8.9
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07#section-8.9>.
it says:

Authorization servers that still require a shared secret for native app
clients MUST treat the client as a public client

As it is a MUST, we have to qualify it a little more as it is ok to treat
it as a confidential client if the client does dynamically register the
copy and obtain shared secret that is only shared between the copy of the
app and the server.

Suggests:

Authorization servers that still require a statically included shared
secret for native app clients MUST treat the client as a public client

NS3: Sever Mix-up
======================
8.11
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07#section-8.11>.
talks about mix-up mitigation but misses one of the points. Specifically:

* the app MUST store the redirect uri in the request with the "session" and
MUST verify that it exactly matches with the URI of the endpoint that it
received the response.

Cheers,

Nat Sakimura

Post by Brian Campbell
-07 LGTM
Hi all,
after the working group last call of the "OAuth 2.0 for Native Apps"
document July last year (see
https://www.ietf.org/mail-archive/web/oauth/current/msg16534.html) I
had, as a shepherd, collected IPR confirmations (see
https://www.ietf.org/mail-archive/web/oauth/current/msg16672.html) and
produced a shepherd writeup (see
https://www.ietf.org/mail-archive/web/oauth/current/msg16702.html).
Since version -03 and the current version -07 a fair amount of text has
been changed, see
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-oauth-native-apps-03.txt&url2=https://tools.ietf.org/id/draft-ietf-oauth-native-apps-07.txt
Although most of those changes are editorial and normative changes have
been discussed on the mailing list I believe it is fair to let the group
take a brief look at the final version.
For this reason we will issue a short, one week, working group last call
before pushing the document to the IESG.
So, please provide your comments to the list no later than February 27th.
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07
Ciao
Hannes & Derek
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[William Denniss]

Thank you for the excellent feedback Nat. I believe I have addressed all
the points you raised in the latest version (08).

Post by Nat Sakimura
It looks generally good. Thanks William and John for creating it.
I spotted a few nits.
NS1: MUST is not a recommendation
================================
(which is a recommended in Section 7.1.1
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07#section-7.1.1>
)
However, in 7.1.1, it is a MUST, i.e., required instead of recommended.
So, "recommended" in the above sentence needs to be changed to "required".
NS2: Dynamically registered client can be treated as a confidential client
=======================================================
In 8.9
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07#section-8.9>.
Authorization servers that still require a shared secret for native app
clients MUST treat the client as a public client
As it is a MUST, we have to qualify it a little more as it is ok to treat
it as a confidential client if the client does dynamically register the
copy and obtain shared secret that is only shared between the copy of the
app and the server.
Authorization servers that still require a statically included shared
secret for native app clients MUST treat the client as a public client
NS3: Sever Mix-up
======================
8.11
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07#section-8.11>.
* the app MUST store the redirect uri in the request with the "session"
and MUST verify that it exactly matches with the URI of the endpoint that
it received the response.
Cheers,
Nat Sakimura

Post by Brian Campbell
-07 LGTM
Hi all,
after the working group last call of the "OAuth 2.0 for Native Apps"
document July last year (see
https://www.ietf.org/mail-archive/web/oauth/current/msg16534.html) I
had, as a shepherd, collected IPR confirmations (see
https://www.ietf.org/mail-archive/web/oauth/current/msg16672.html) and
produced a shepherd writeup (see
https://www.ietf.org/mail-archive/web/oauth/current/msg16702.html).
Since version -03 and the current version -07 a fair amount of text has
been changed, see
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/
id/draft-ietf-oauth-native-apps-03.txt&url2=https://
tools.ietf.org/id/draft-ietf-oauth-native-apps-07.txt
Although most of those changes are editorial and normative changes have
been discussed on the mailing list I believe it is fair to let the group
take a brief look at the final version.
For this reason we will issue a short, one week, working group last call
before pushing the document to the IESG.
So, please provide your comments to the list no later than February 27th.
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07
Ciao
Hannes & Derek
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth