Sounds interesting! Thanks Ulrich
On Wed, Aug 3, 2016 at 3:30 PM, John Bradley <[email protected]> wrote: > Inline > >> On Apr 15, 2016, at 1:10 AM, Ulrich Herberg <[email protected]> wrote: >> >> 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. > > >> Thanks >> Ulrich >> >> On Mon, Apr 4, 2016 at 10:09 AM, Ulrich Herberg <[email protected]> wrote: >>> 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 >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
