Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
+1 I have too this very same worry. However the question isn't actually specific to desktop environments or Twitter - this authentication schema is very common amongst webservices I believe? –  vemv Aug 8 '11 at 4:31
    
Because your question can be abstracted to something like "how to store secret data on a client" I think you may be able to attract more answers if you post a new question that is less twitter-specific. IMO. –  Jeff Welling Aug 8 '11 at 6:37
1  
+1 I'm also curious about what the best practice is here. In my Qt application I use OAuth but I just store the Consumer details as strings (QString) in the binary. –  fejd Aug 8 '11 at 14:39
1  
Jeff, their is a very good possibility I am doing something completely wrong with OAuth. I am starting to get the feeling that I amsupposed to use the consumer key/secret pair to generate temporary secrets and that having a web service to generate those secrets somewhere is the way to go. Generalizing this question beyond OAuth will miss answers like that. –  Justin Dearing Aug 8 '11 at 15:06

4 Answers 4

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.

share|improve this answer

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.

share|improve this answer

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 ;)

share|improve this answer
2  
Its not about trying to control with they do with the program, its about people misrepresenting themselves. The comsumer key and secret is how I tell twitter "this app came by me" much like a SSL certificate provides trust. I would never distribute a SSL cert with a web app I wrote. If people modify my app, they should indeed apply for their own Consumer key/secret and register themselves as the app author from twitter for their build. –  Justin Dearing Aug 8 '11 at 9:25
    
Excellent point, I had a sneaking suspicion that's what the consumer key was for but didn't know for sure. In that case, to be honest, I don't think there is a way to protect your app. To me this sounds like twitter chose that method so that mobile apps can be written but desktop ones cannot - mobile platforms are largely locked down. In this case the best way to go IMO is to put the key in a separate file or variable which you do not release with the source code. To my knowledge this does not go against the GPL. I would love to be proven wrong on any or all of this though.. –  Jeff Welling Aug 8 '11 at 11:19

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.