This is a known issue with protecting resources in desktop / mobile
applications in general. I myself have brought it up in the OAuth spec
list and you can feel free to read the thread referenced below.
The consensus, which I agree with is, that while it is impossible to
completely safe guard OAuth key material from a would-be client-side
bad guy, OAuth still has significant advantages over other, more
traditional authorization options on the desktop. 1) OAuth requests
generally do not have the ability to change or reset user passwords
(the most common form of local authentication. Generally
authentication of last resort.); 2) OAuth authorization tokens may be
That said, it is a risk, and as with any authorization and/or
authentication implementation, developers should familiarize
themselves with them.
Further reading at:
On Thu, Dec 10, 2009 at 9:09 PM, Dewald Pretorius <dpr...@gmail.com> wrote:
> OAuth poses a very real risk for any downloadable application. Think
> TweetDeck. Think Tweetie. Etc.
> I'm not an expert at OAuth, but if my understanding is correct, then
> an application will either have to include its Consumer Key Secret in
> its compiled code (which most will probably do), or dynamically
> request it from its host server (which breaks offline usage).
> Now, will there be hackers and scammers that will decompile
> TweetDeck's code to get their grubby hands on its Consumer Key Secret?
> You bet your bottom dollar there will be. Many.
> Once they have that, they can spam the living shits out of Twitter,
> and there is nothing, NOTHING, Twitter can do to stop it.
> TweetDeck cannot request or generate a new Consumer Key Secret,
> because that breaks all its currently installed apps.
> Twitter cannot block by app because they will disable all legitimate
> TweetDeck users. And they cannot block by IP address, if the scammers
> are clever in their use of proxies.
> Just a thought...