Michael, On Sep 6, 2011, at 1:40 PM, Michael Thomas wrote:
> Hi all, > > Barry suggested that I might subscribe and explain what I sent him. > > My basic problem is that in neither the protocol nor the threats drafts, > I can't seem to find what problem is actually trying to be solved with > oauth, and what assumptions you're making about various elements. > > Here's what I did. I've written an app, and I wanted re-integrate the > ability to send tweets after they deprecated Basic. So the app has a > webView (android, iphone...) which it obviously completely controls. > With oauth, the webview UA will ultimately redirect off to Twitter's > site to collect the user's credentials and grant my app's backend an > access token (sorry if I get terminology screwed up, i'm just coming > up to speed). > > What occurs to me is that webview affords exactly zero protection from > my client (ie, the app) from getting the user's twitter credentials. All > I have to do is set up a keypress handler on that webview and in a few > minutes of hacking I have a key logger. etc. If an attacker is able to log key presses from a "webview" created by your app with their own app/library, then this is a threat to the user's credentials, yes. > > So what I can't tell is whether this is a "problem" or not, because I > don't know what problem you're trying to solve. Broadly-speaking, the "problem" to be solved is to avoid the requirement for a user to share her username/password at one web application with another. OAuth is similar in that regard to Kerberos or SAML - a "ticket" system. > If the object of oauth > isn't to keep user/server credentials out of the hands of a third party, > then what is it trying to solve? Is there an expectation that the > UA is trusted by the user/server? Not in all cases, no. It depends on which OAuth "flow" you use for your application. In general, I would say that the UA is NOT to be trusted by the user/server. > What happens when that's not the case? > > Regardless of whether I'm misunderstanding, it would sure be nice to have > both the problem and your assumptions laid out, hopefully with some prominence > so you don't get these sort of dumb questions. One point I would mention first is that your question isn't dumb ;) But, as I noted, OAuth seeks to avoid the requirement for a user to share her username/password at one web application with another. That being said, there are lots of ways to get that wrong, and the way of resolving those is to implement OAuth-based applications using the security features available in their specific environments, as these vary quite a lot. OAuth provides a number of different protocol flows to help with that, and "security considerations" that discuss known security threats within various environments. By careful reading, you can determine which flow is appropriate for your application, and which security features should be used to avoid the threats to your application. Regards, - John > > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
