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
