 |
 |
Well, if you want to distribute an application to users that will enable them to log in to _their own personal information_, without them ever having to enter credentials in a workflow started by that application, that's not going to happen, cause it's kind of impossible. But if you just want to "publish an OAuth-using client that's not easy to impersonate" -- well, it depends on what you mean. Do you mean you want the server to know that the client application, that is distributed to end-users, is "The Twitterific Client", in a crypto-secure way? You indeed can not do that. This is not OAuth's fault, it's the universe's fault. There is no way to do this absolutely reliably, although the DRM people sure try, and Facebook tried, causing the problems that blogger was complaining about. There's no other solution that will do that either, it's not a unique failing of OAuth, and it's not the problem domain OAuth was trying to solve, mainly. Do you not care about authenticating that the client software is "The Twitterific Client", but you just care about knowing that Joe Smith has authorized it (whatever it is) to access Joe Smith's twitter account? Ah, now THAT is indeed the use case of OAuth. The first one was not the use case of OAuth, and Facebook trying to use OAuth anyway to accomplish it is what causes the problems. How do you do this? By, as mentioned in the blog post you cited, following the OAuth specs recommendations, unlike Twitter: "In many applications, the Consumer application will be under the control of potentially untrusted parties. For example, if the Consumer is a freely available desktop application, an attacker may be able to download a copy for analysis. In such cases, attackers will be able to recover the Consumer Secret used to authenticate the Consumer to the Service Provider. Accordingly, Service Providers should not use the Consumer Secret alone to verify the identity of the Consumer." [right from the OAuth spec; that Twitter may have ignored this is not OAuth's fault]. Yes, to do this, OAuth requires one of two workflows, neither ideal: 1) Redirect to Twitter where the user logs in, and is then redirected back (Ie, similar to Shibboleth or other SSO flows we may be familiar with). Problems -- A) this may be hard to do in a non-web applications. B) Succeptible to fishing. [Note Shibboleth, OpenID, and most other SSO login systems have the exact same issues]. 2) Have the user enter their twitter login/password directly in client application, which then sends it on to twitter. Problem: Giving your twitter credentials to someone else. It's a _little_ bit better than it seems because the OAuth framework allows the client app to immediately discard those credentials after using them to get a token from Twitter, so the client doesn't have to be responsible for ongoing protection of sensitive information. Not ideal, true. But no other solution is going to do better, because that's just how the universe works, unless some genius can come up with something nobody's thought of yet. Your arguments are against implementing OAuth poorly, and a useful reminder that doing anything security related requires thinking carefully, and OAuth doesn't get us out of that with an automatic solution that will Just Work without thinking. But your arguments are not against OAuth. Maybe they're against trying to do remote authentication between two servers AT ALL because of the inherent problems with such, heh. Jonathan MJ Ray wrote: > Jonathan Rochkind wrote: > >> Can you give some details (or references) to justify the belief that >> OAuth isn't ready yet? (The fact that Twitter implemented it poorly >> does not seem apropos to me, that's just a critique of Twitter, right?). >> >> I don't agree or disagree, just trying to take this from fud-ish rumor >> to facts to help me and others understand and make decisions. >> > > The problems with Twitter's poor implementation have been compounded > by bad management decisions like switching off HTTP authentication and > an amazing policy on key invalidation, but I agree that's not the > fault of OAuth. > > The key point is in the http://bit.ly/c88aa7 that Joe posted: how can > one publish an OAuth-using client that's not easy to impersonate? > > Requiring every user to fill out registration forms and cut-and-paste > key strings into a client is not going to fly, so it seems like it > can't be done except on a very locked-down platform, because the > consumer secret is distributed to users' systems in the app. So you > either ignore the key parts of the 1.0a version (which means that the > standard needs revision IMO, so is not ready yet), or you jump ahead > to the 2.0 draft, which is not ready yet because it's still a draft. > > Personally, I think the right answer would have been to keep HTTP > authentication over HTTPS and have some slick way of creating > subsidiary usernames with limited privileges for apps, but there's > probably some better solution that I'm missing. > > Aside 1: will 2.0 ever work and be ready? Its editor Eran > Hammer-Lahav criticises its current state at > http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/ > > Aside 2: to be fair, I'll point out that Eran Hammer-Lahav criticises > the ars.technica article at > http://hueniverse.com/2010/09/all-this-twitter-oauth-security-nonsense/ > but does mention that "there is no solution [...] for a distributed > application" - does that mean OAuth isn't fit for FOSS? > > Hope that helps, >