While it's on my mind thinking about implementation for the StatusNet Mobile client...

There's been a lot of hullaballoo recently about Twitter's OAuth implementation for their API access, and how their policies about application's secret keys are problematic especially for open-source clients:

http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars

Here at StatusNet obviously we love open source... we also want to learn from the mistakes of others! ;)

The big difficulty of using OAuth instead of passwords for a client application is that your app needs to be registered with the host site to get a secret key pair, used to identify the client. There are two big problems with this:

First, if you're trying to access a distributed service like StatusNet, it's not feasible to require client authors to register their app with *every server*, and it's too onerous on end-users to ask them to register your app themselves.

Second, these secret keys can only actually be kept _secret_ if you don't distribute the software -- generally fine for web apps that run on a single host, but totally unsuitable for client-side applications that are widely distributed.


Twitter's avoided the first problem by being a centralized service, and is having a terrible time with the second problem by trying to enforce key secrecy where it's not actually possible.


I'd like to propose following the example of OAuth implementations like those at Google and Facebook, which are allowing desktop-style apps to use a dummy key or skip the key altogether.

This allows client apps to gain from the real security benefits of switching from plaintext passwords stored locally and sent with every request to using secure tokens which can be restricted or revoked, without trying to enforce an impractical client software identification policy.


Clients connecting with a dummy key would be given the same level of trust as clients connecting with HTTP basic auth: we know they're acting on behalf of the user since they have his/her credentials, but we can't know for sure what software they are -- so eg the 'source' parameter saying 'Mustard' or 'StatusNet Mobile' could be faked, so we know we can't reliably use it to throttle or limit particular clients.

Any thoughts?

-- brion vibber (brion @ status.net)
_______________________________________________
StatusNet-dev mailing list
[email protected]
http://lists.status.net/mailman/listinfo/statusnet-dev

Reply via email to