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