What are the risks of exposing a not so secret oauth key? Are there any workarounds?

Question

I am currently developing a multi-platform application that uses Twitter, including authentication through oAuth.

I looked through a lot of existing applications, and most of them seem to insert both the identifier and the secret key inside the application.

What are the risks to this? Is it just that someone can “download and verify” your binary application to extract your key, and can it pretend to be your application (phishing style)? Or are there other risks?

---

Besides risks, are there any workarounds or solutions that people know about?

The only solution I’ve already seen is that some people get around this by routing all twitter calls through their own website - for example, OAuth Twitter using only the consumer key (do not use a user's secret) on iPhone and Android - but this seems rather slow and expensive - I would prefer not to route all calls through my own web service if I can avoid it (or did I misunderstand the solution - is it just authorization that goes through the website?)

Answer 1

The only real danger, apparently, is that someone can impersonate your application and prevent it from using Twitter, and then you must use a new key.

There are some guidelines for obfuscating the code in this Google I / O talk to make it harder to reconstruct. http://www.google.com/events/io/2011/sessions/evading-pirates-and-stopping-vampires-using-license-verification-library-in-app-billing-and-app-engine.html

Answer 2

The workaround I came up with is to get the secret key from your web server (via SSL) using an authenticated web service call. You can cache it in a client application (only in memory). Use it when you need, without connecting again to the server.

The drawback that I see is that someone can probably still run your application under the debugger and check the memory and get the key.