Discussion:
[OAUTH-WG] draft-ietf-oauth-native-apps-01
Ulrich Herberg
2016-04-04 17:09:38 UTC
Permalink
Hi,

I have read draft-ietf-oauth-native-apps-01 and I generally agree with
the overall recommendations in the draft, and it is well written (I
haven't participated in this WG before, so I don't know what to what
level it has already been discussed).

Some comments:
- Section 2, last paragraph:
I agree with the general recommendation to not use an external user
agent because of complexity. However, there are cases when a tablet is
sold as a closed system and under full control of the vendor. In these
cases, the vendor can preinstall the AS user agent into the operating
system and provide APIs for other apps to use it.


- Section 5.1 (Embedded User-agents): "Authorization servers SHOULD
consider taking steps to detect and block logins via embedded
user-agents that are not their own, where possible."

Do you have any recommendation how to do that, other than reading the
(easily modifiable) User-Agent HTTP header? Maybe you could add a
sentence for providing some guidance here.


- Section 5.3 (Phishing):
This is indeed concerning; it's very easy to fake the in-app browser.
The draft says: "If all native apps use the techniques described in
this best practice, users will not need to sign-in frequently and thus
should be suspicious of any sign-in request when they should have
already been signed-in."

That is true, in theory, but sounds like a big "if" to me. Most users
are not savvy enough to be suspicious if a login screen appears and it
looks the same as the one they know.
I admit that I don't have any suggestion how to do it better, but this
part seems to be the most problematic to me for using OAuth on native
devices.

Best regards
Ulrich
Ulrich Herberg
2016-04-15 05:10:41 UTC
Permalink
Hi,

I was wondering if you had any thoughts about my comments below from
my other email?

In addition, I was wondering about the case where the client ID and
client secret of an app has been leaked. The draft mentions the case
where a rogue app intercepts the auth code by using the same redirect
URL scheme of another app and how to mitigate that with PKCE.
But how could you prevent the rogue app from pretending to be another
app in case it got hold of the Client ID and Client Secret of that
app? In that case, couldn't it initiate the auth request (and thereby
pass the PKCE verification correctly)?

Thanks
Ulrich
Post by Ulrich Herberg
Hi,
I have read draft-ietf-oauth-native-apps-01 and I generally agree with
the overall recommendations in the draft, and it is well written (I
haven't participated in this WG before, so I don't know what to what
level it has already been discussed).
I agree with the general recommendation to not use an external user
agent because of complexity. However, there are cases when a tablet is
sold as a closed system and under full control of the vendor. In these
cases, the vendor can preinstall the AS user agent into the operating
system and provide APIs for other apps to use it.
- Section 5.1 (Embedded User-agents): "Authorization servers SHOULD
consider taking steps to detect and block logins via embedded
user-agents that are not their own, where possible."
Do you have any recommendation how to do that, other than reading the
(easily modifiable) User-Agent HTTP header? Maybe you could add a
sentence for providing some guidance here.
This is indeed concerning; it's very easy to fake the in-app browser.
The draft says: "If all native apps use the techniques described in
this best practice, users will not need to sign-in frequently and thus
should be suspicious of any sign-in request when they should have
already been signed-in."
That is true, in theory, but sounds like a big "if" to me. Most users
are not savvy enough to be suspicious if a login screen appears and it
looks the same as the one they know.
I admit that I don't have any suggestion how to do it better, but this
part seems to be the most problematic to me for using OAuth on native
devices.
Best regards
Ulrich
John Bradley
2016-08-03 22:30:03 UTC
Permalink
Inline
Post by Ulrich Herberg
Hi,
I was wondering if you had any thoughts about my comments below from
my other email?
In addition, I was wondering about the case where the client ID and
client secret of an app has been leaked. The draft mentions the case
where a rogue app intercepts the auth code by using the same redirect
URL scheme of another app and how to mitigate that with PKCE.
But how could you prevent the rogue app from pretending to be another
app in case it got hold of the Client ID and Client Secret of that
app? In that case, couldn't it initiate the auth request (and thereby
pass the PKCE verification correctly)?
This spec is not intended to stop app impersonation.
PKCE os no help with this.

William and I are also working on an attestation spec that will allow the OS to attest to an applications developer key and bundle ID.
To do that securely we want to use token binding to bind the attestation to the app making the call to a token endpoint.

It is different enough, and has a number of dependencies on new work that we did not want to block getting these best practices out, on new work.

I agree that app impersonation will become a real problem, but one step at a time.

John B.
Post by Ulrich Herberg
Thanks
Ulrich
Post by Ulrich Herberg
Hi,
I have read draft-ietf-oauth-native-apps-01 and I generally agree with
the overall recommendations in the draft, and it is well written (I
haven't participated in this WG before, so I don't know what to what
level it has already been discussed).
I agree with the general recommendation to not use an external user
agent because of complexity. However, there are cases when a tablet is
sold as a closed system and under full control of the vendor. In these
cases, the vendor can preinstall the AS user agent into the operating
system and provide APIs for other apps to use it.
- Section 5.1 (Embedded User-agents): "Authorization servers SHOULD
consider taking steps to detect and block logins via embedded
user-agents that are not their own, where possible."
Do you have any recommendation how to do that, other than reading the
(easily modifiable) User-Agent HTTP header? Maybe you could add a
sentence for providing some guidance here.
This is indeed concerning; it's very easy to fake the in-app browser.
The draft says: "If all native apps use the techniques described in
this best practice, users will not need to sign-in frequently and thus
should be suspicious of any sign-in request when they should have
already been signed-in."
That is true, in theory, but sounds like a big "if" to me. Most users
are not savvy enough to be suspicious if a login screen appears and it
looks the same as the one they know.
I admit that I don't have any suggestion how to do it better, but this
part seems to be the most problematic to me for using OAuth on native
devices.
Best regards
Ulrich
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Ulrich Herberg
2016-08-04 15:37:52 UTC
Permalink
Sounds interesting!

Thanks
Ulrich
Post by John Bradley
Inline
Post by Ulrich Herberg
Hi,
I was wondering if you had any thoughts about my comments below from
my other email?
In addition, I was wondering about the case where the client ID and
client secret of an app has been leaked. The draft mentions the case
where a rogue app intercepts the auth code by using the same redirect
URL scheme of another app and how to mitigate that with PKCE.
But how could you prevent the rogue app from pretending to be another
app in case it got hold of the Client ID and Client Secret of that
app? In that case, couldn't it initiate the auth request (and thereby
pass the PKCE verification correctly)?
This spec is not intended to stop app impersonation.
PKCE os no help with this.
William and I are also working on an attestation spec that will allow the OS to attest to an applications developer key and bundle ID.
To do that securely we want to use token binding to bind the attestation to the app making the call to a token endpoint.
It is different enough, and has a number of dependencies on new work that we did not want to block getting these best practices out, on new work.
I agree that app impersonation will become a real problem, but one step at a time.
John B.
Post by Ulrich Herberg
Thanks
Ulrich
Post by Ulrich Herberg
Hi,
I have read draft-ietf-oauth-native-apps-01 and I generally agree with
the overall recommendations in the draft, and it is well written (I
haven't participated in this WG before, so I don't know what to what
level it has already been discussed).
I agree with the general recommendation to not use an external user
agent because of complexity. However, there are cases when a tablet is
sold as a closed system and under full control of the vendor. In these
cases, the vendor can preinstall the AS user agent into the operating
system and provide APIs for other apps to use it.
- Section 5.1 (Embedded User-agents): "Authorization servers SHOULD
consider taking steps to detect and block logins via embedded
user-agents that are not their own, where possible."
Do you have any recommendation how to do that, other than reading the
(easily modifiable) User-Agent HTTP header? Maybe you could add a
sentence for providing some guidance here.
This is indeed concerning; it's very easy to fake the in-app browser.
The draft says: "If all native apps use the techniques described in
this best practice, users will not need to sign-in frequently and thus
should be suspicious of any sign-in request when they should have
already been signed-in."
That is true, in theory, but sounds like a big "if" to me. Most users
are not savvy enough to be suspicious if a login screen appears and it
looks the same as the one they know.
I admit that I don't have any suggestion how to do it better, but this
part seems to be the most problematic to me for using OAuth on native
devices.
Best regards
Ulrich
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
John Bradley
2016-08-03 22:22:31 UTC
Permalink
Sorry I missed your comments.

Inline
Post by Ulrich Herberg
Hi,
I have read draft-ietf-oauth-native-apps-01 and I generally agree with
the overall recommendations in the draft, and it is well written (I
haven't participated in this WG before, so I don't know what to what
level it has already been discussed).
I agree with the general recommendation to not use an external user
agent because of complexity. However, there are cases when a tablet is
sold as a closed system and under full control of the vendor. In these
cases, the vendor can preinstall the AS user agent into the operating
system and provide APIs for other apps to use it.
Yes that is possable but this document is not describing how to use such an external token agent.
That needs to be a separate spec. We did start one called NAPPS in the OpenID foundation but have largely abandoned it due to to the complexity of also needing to change OAuth to support that model.

It can be done but so far only in a relatively closed environment. For applications that need to work with multiple authentication servers the model of doing OAuth via a system browser seems the most strait-forward.

We are recommending not doing it and saying if you want to it is out of scope. If you have some specific text you would like to see let us know.
Post by Ulrich Herberg
- Section 5.1 (Embedded User-agents): "Authorization servers SHOULD
consider taking steps to detect and block logins via embedded
user-agents that are not their own, where possible."
Do you have any recommendation how to do that, other than reading the
(easily modifiable) User-Agent HTTP header? Maybe you could add a
sentence for providing some guidance here.
At the moment looking at the browser strings and blacklisting client id of apps that fake them is the only thing we have at the moment.

I think Google is currently looking into this and William may have more information.
Post by Ulrich Herberg
This is indeed concerning; it's very easy to fake the in-app browser.
The draft says: "If all native apps use the techniques described in
this best practice, users will not need to sign-in frequently and thus
should be suspicious of any sign-in request when they should have
already been signed-in."
That is true, in theory, but sounds like a big "if" to me. Most users
are not savvy enough to be suspicious if a login screen appears and it
looks the same as the one they know.
I admit that I don't have any suggestion how to do it better, but this
part seems to be the most problematic to me for using OAuth on native
devices.
I don’t think we have any magic bullet for fake apps.
There are some techniques to cookie the browser with the users photo or other information that will be harder to fake outside the real browser.
Un-phishable credentials like Fido may be the only long term answer for this, but at least this recommendation of using the system or external browser make using Fido possable where U2F atleast is blocked from webviews currently.

John B.
Post by Ulrich Herberg
Best regards
Ulrich
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Ulrich Herberg
2016-08-04 15:37:10 UTC
Permalink
Thanks, John. Do you think that for the last two of my points it would
be useful to add some informative text to the draft, similar to the
answer you provided in your email?

Regards
Ulrich
Post by John Bradley
Sorry I missed your comments.
Inline
Post by Ulrich Herberg
Hi,
I have read draft-ietf-oauth-native-apps-01 and I generally agree with
the overall recommendations in the draft, and it is well written (I
haven't participated in this WG before, so I don't know what to what
level it has already been discussed).
I agree with the general recommendation to not use an external user
agent because of complexity. However, there are cases when a tablet is
sold as a closed system and under full control of the vendor. In these
cases, the vendor can preinstall the AS user agent into the operating
system and provide APIs for other apps to use it.
Yes that is possable but this document is not describing how to use such an external token agent.
That needs to be a separate spec. We did start one called NAPPS in the OpenID foundation but have largely abandoned it due to to the complexity of also needing to change OAuth to support that model.
It can be done but so far only in a relatively closed environment. For applications that need to work with multiple authentication servers the model of doing OAuth via a system browser seems the most strait-forward.
We are recommending not doing it and saying if you want to it is out of scope. If you have some specific text you would like to see let us know.
Post by Ulrich Herberg
- Section 5.1 (Embedded User-agents): "Authorization servers SHOULD
consider taking steps to detect and block logins via embedded
user-agents that are not their own, where possible."
Do you have any recommendation how to do that, other than reading the
(easily modifiable) User-Agent HTTP header? Maybe you could add a
sentence for providing some guidance here.
At the moment looking at the browser strings and blacklisting client id of apps that fake them is the only thing we have at the moment.
I think Google is currently looking into this and William may have more information.
Post by Ulrich Herberg
This is indeed concerning; it's very easy to fake the in-app browser.
The draft says: "If all native apps use the techniques described in
this best practice, users will not need to sign-in frequently and thus
should be suspicious of any sign-in request when they should have
already been signed-in."
That is true, in theory, but sounds like a big "if" to me. Most users
are not savvy enough to be suspicious if a login screen appears and it
looks the same as the one they know.
I admit that I don't have any suggestion how to do it better, but this
part seems to be the most problematic to me for using OAuth on native
devices.
I don’t think we have any magic bullet for fake apps.
There are some techniques to cookie the browser with the users photo or other information that will be harder to fake outside the real browser.
Un-phishable credentials like Fido may be the only long term answer for this, but at least this recommendation of using the system or external browser make using Fido possable where U2F atleast is blocked from webviews currently.
John B.
Post by Ulrich Herberg
Best regards
Ulrich
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Loading...