33

I want to make a thick-client, desktop, open source twitter client. I happen to be using .NET as my language and Twitterizer as my OAuth/Twitter wrapper, and my app will likely be released as open source.

To get an OAuth token, four pieces of information are required:

  1. Access Token (twitter user name)
  2. Access Secret (twitter password)
  3. Consumer Key
  4. Consumer Secret

The second two pieces of information are not to be shared, like a PGP private key. However, due to the way the OAuth authorization flow is designed, these need to be on the native app. Even if the application was not open source, and the consumer key/secret were encrypted, a reasonably skilled user could gain access to the consumer key/secret pair.

So my question is, how do I get around this problem? What is the proper strategy for a desktop Twitter client to protect its consumer key and secret?

Justin Dearing
  • 879

5 Answers5

5

I found an answer that mirrors the path I was considering going down on hueniverse. The article, Beyond the OAuth Web Redirection Flow, offers some suggestsions, one of them being a web url that proxies the token exchange process. I have to work out a way to properly authenticate that my app is what is requesting the authentication to this proxy page. However, that is possible.

Matt
  • 103
Justin Dearing
  • 879
5

Section 4.6 of RFC 5849, which defines OAuth 1, states that the consumer secret was never intended for use by desktop consumers, despite Twitter's use thereof in practice. As Nelson Elhage pointed out in "Dear Twitter", Twitter can and does terminate consumer keys of desktop clients, provided that the client isn't too big to fail. But there are two workarounds to allow use of OAuth 1 in a desktop or mobile application.

One way is to proxy the entire Twitter protocol through a server that you operate. This way, the consumer secret stays on your server. This is the workaround recommended by Dick Hardt, editor of the OAuth 1 spec. This workaround does not address the cost of operating this server.

The other way, as suggested in a post by Raffi Krikorian to the Twitter development talk Google group and a post by Chris Steipp to a Wikipedia mailing list, is to "have each user register their copy of your desktop application as its own consumer." Then the user would copy and paste the newly registered consumer key and consumer secret into your application. The manual for your application would then need to include detailed instructions on how to register a new application on Twitter's developer site. This official limitation has a few practical problems:

  • Your client will face a usability disadvantage compared to well-known proprietary clients.
  • The form to create a new app doesn't appear to offer a way to pre-populate the required fields. This means you will have to update the registration walkthrough in your manual whenever Twitter changes the procedure for registering an app.
  • The developer agreement requires users to be of legal age to enter a binding contract. This means a user of your application aged 13 to 17 must have a parent accept the agreement on the user's behalf.
  • Twitter's Developer Policy prohibits mass-registering applications and "name squatting", which it defines as "submitting multiple applications with the same function under different names." I am unaware of any precedent as to whether Twitter has treated unrelated users who have registered separate copies of one application as "name squatters".
Community
  • 1
Damian Yerrick
  • 309
4

I may be wrong, but if you bundle keys with the desktop or mobile app, open source or not, it is possible to access them. If services like Twitter and Tumblr force us into using OAuth-only API, we have two options:

  • setup an auth proxy service for every app
  • bundle keys with the app

The former is more difficult and costly, not necessarily maintainable for small and open source apps. The latter means that the app may and will be blocked, once the spammers steal the keys. As Twitter and Tumblr don't give a better option yet, and screw all desktop clients, Open Source clients inclusive, there is a proposal to distribute "Big Fish" keys, and use them as a fallback.

Finally, there is an option to force every user into obtaining API keys.

sastanin
  • 141
-1

I'm going to answer but be warned I have not dealt with this myself, I am going off of best practices and existing relevant experience;

I wouldn't worry about it too much. If your client is open source then they are going to have access to the source anyway, and trying to control what they do with your program goes against the nature of open source anyway (though importantly, what you are trying to do does not).

If someone has enough knowledge to debug your program and extract your key, they likely know how to do more than that and you could very well be wasting your time trying to lockdown further.

As a precaution I would change keys every so often (if possible), but if all they can do is pretend to be your program than that doesn't sound too serious to me.

Full disclosure, I am not familiar with Twitters API, twitterizer's API, oauth requirements, or anything else I said that sounds questionable ;)

Jeff Welling
  • 1,279
-3

The consumer key and secret are application bound and not user bound. With this in formation the OAuth provider knows with what application it is dealing. The rest, Access token and secret will be obtained after the first steps are done.

See this blog post for more information as it shows how the protocol works.

Adam Lear
  • 32,069
Yblih
  • 1