2
votes

I have been working on setting up a service provider and saw that, to make a request on behalf of a user, all that seems to be needed is the Consumer Key/Secret and the Token Key/Secret.

What stops a consumer from registering with my service provider, getting some users to authorize access to some of their data, and then giving the access token and consumer information away to a 3rd party?

Does this come down to a trust issue that we have to put trust in our consumers that they wouldn't do this? Is there any way we can prevent this kind of activity via any monitoring? We want to provide an OAuth solution but we don't want to have to worry extensively about a malicious consumer.

Thanks for any insight.

1

1 Answers

1
votes

There are four tokens involved in Twitter's OAuth implementation.

  1. Consumer Key
  2. Consumer Key Secret
  3. OAuth Token
  4. Oauth Token Secret

In the case of a web application, the end user never has access to tokens 1 & 2 because they're never transmitted to the client. The communication with the Twitter API is server-to-server. In this scenario, there's less risk.

In the case of a desktop application, the "Consumer" keys are usually embedded in the binary in some way. This is an acknowledged security problem with Twitter's implementation of OAuth. A determined person can decompile/crack/unobfuscate just about any binary to get your Consumer Keys.

So, to answer your question: In the case of desktop/mobile apps, it's absolutely a question of trust. In the case of web apps, it is less so.