 |
 |
Jonathan Rochkind wrote: [...] > 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. Mainly? Why does it include something that even looks like a solution to a problem that is actually insoluble? What problem was it trying to solve? If it was "a process for end-users to authorize third-party access to their server resources without sharing their credentials" then I feel a simpler method is possible, as described below. (Quote from RFC 5849) > 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. What is the use case? http://oauth.net/core/1.0a/ claimed "OAuth creates a freely-implementable and generic methodology for API authentication." Shouldn't we expect generic authentication to include authenticating both peers? I feel that OAuth has tried to be jack of all trades. > 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]. I think we're rehashing what's written in links already posted, but that section continues "Where possible, other factors such as IP address should be used as well" which seems somewhat inadequate as an authentication component. The specs don't really give any positive direction on how to handle published Consumer applications, so I feel it's not surprising that Twitter and others filled the vacuum with silliness. > 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 [...] > 2) Have the user enter their twitter login/password directly in client > application, which then sends it on to twitter. [...] > 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. The authentication workflow isn't the problem. It's this consumer secret nonsense. I've been pointed at Yahoo's CCK which looks like an API to work around this problem with OAuth: http://developer.yahoo.com/oauth/guide/create-consumer-key-guide.html But what's wrong with the idea of a CCK-like way of creating a subsidiary username with limited privileges and communicating that back to the app for use? The authentication workflow can even be the same. In other words, apart from this consumer secret confusion, what does OAuth add to this field which wasn't already there with HTTPS authentication and cookies? Confused, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha