The worst that happens if you publish the consumer tokens in an
opensouce app is someone malicious uses it to abuse Twitter and the
consumer token gets banned. At which point you regenerate a new one
and push a new version of the app. The cycle may or may not start
again depending on the malicious party.

They can not act upon user accounts without the users going through
the authorize flow. Using basic auth it is already possible to use any
source and "impersonate" another application so not much is changing
here except better security for web applications.


On Wed, Jul 1, 2009 at 08:25, DWRoelands<> wrote:
> If you check out the OAuth Core Abstract, Section 4 (
> core/1.0#anchor4) states it pretty plainly:
> "Service Providers SHOULD NOT rely on the Consumer Secret as a method
> to verify the Consumer identity, unless the Consumer Secret is known
> to be inaccessible to anyone other than the Consumer and the Service
> Provider."
> This is exactly what Twitter has done with the Consumer Secret; they
> rely on it to verify the Consumer identity.
> This is a thorny dilemma for open source developers.  There's no way
> to share the source code without compromising your application's
> security, because you've got to include the Consumer Key Secret in the
> source.  You can obfuscate and encrypt, but a malicious actor with
> access to the source code can simply "step through" the code until the
> Consumer Secret is exposed in plain text.
> In any event, what's done is done, and Twitter certainly isn't going
> to abandon OAuth at this point.  But opening the source of my Twitter
> client seems to be out of the question if I want to use OAuth.
> On Jul 1, 8:10 am, Philip Plante <> wrote:
>> I do not feel you've made a mountain out of a mole hill here.  This
>> topic has been on my mind since I first encountered oAuth.  I haven't
>> seen any open source apps use oAuth yet.

Abraham Williams | Community Evangelist |
Hacker | |
Project |
This email is: [ ] blogable [x] ask first [ ] private.

Reply via email to