Recently I was listening to Security Now when the topic of OAuth keys being hacked out of Android applications came up. There was some discussion on how services that require OAuth for authentication (as Twitter now does) cause problems for client applications. (NB: In this post I’m referring to client applications specifically as something that the end user downloads to their PC or other device.) The case was made that the problem is that OAuth was not written for client development, and is really only secure when running from a web-server.
The key to the “vulnerability” with OAuth is that each application is given its own key. That key ties any request made to the service (Twitter for example) to the application which owns the key. The concern was that if the key falls into the wrong hands users’ personal information could be put at risk. With the key needing to reside somewhere that the application can read it, they’re typically stored within the application code which makes finding the key a trivial matter for a hacker.
The thought occurred to me that if you need to access a web-based service which requires OAuth, it might be helpful to have an intermediary service handle that authentication for you. By adding a service tier which authenticates a specific user of your application and performs all of the direct interaction with the service there’s no need to keep the OAuth keys on the client which makes them much more difficult to compromise.

Google today
Here’s a clip of a post I did over on the AGP Blog about the acquisition of