Essentially no client side app can be considered able to keep secrets.

I would be interested in the implications of this from the authorising servers perspective. Here is the main mention of it in the OAuth spec: http://tools.ietf.org/html/rfc6749#page-52 and google's interpretation: https://developers.google.com/accounts/docs/OAuth2InstalledA.... Even though google say "t is assumed that these applications cannot keep secrets" I can't quite infer the actual implications of this?

Incidentally, this exact topic is now under discussion: http://news.ycombinator.com/item?id=5337099

> So anyone with some basic Android knowledge will be able to extract my applications key and secret?

Yes:

http://news.ycombinator.com/item?id=4410398

http://stackoverflow.com/questions/4419915/how-to-keep-the-o...

Yes. This is also how Twitter's authentication works. Twitter say that client developers should protect the secret in the binary by reasonable means, but the key from Twitter's own iOS and Android apps have already been extracted. (on a side note, why haven't any client devs who ran into token limited tries using the official keys yet? will they be taken out of an app store?)

> why haven't any client devs who ran into token limited tries using the official keys yet? will they be taken out of an app store?

Probably, just like AirFoil Speakers Touch has been kicked out for using some Apple private key extracted from the Airport firmware to act as an AirpLay receiver.

The APP credentials are for each app that integrates this Dropbox sync. The app keeps those to itself (probably hard-coded in the binary) and using them, it requests access to a Dropbox account.

Yep. And the same goes for iOS, too. I've taken a peek at the official Dropbox iOS app's API key and secret in the past just for fun, though I didn't go so far as to post them on Github.

Is there a way round that thou?

Surely you need to grant your app to be able to indentify itself, that means it has to have its secret baked in?

There isn't really a way around it other than implementing authentication in a remote server. In that scenario, the app doesn't authenticate directly with the service, but with a private server. This way you can, for example, authenticate your users and create sessions before they can access the Dropbox API.

It can still be abused, but at least you can know who did it.

How about storing the key and secret in an encrypted form?

And where would you keep the decryption key?

Keychain.