There is a difference between giving your application to others to install
and use, and others downloading your code for their own applications.

If a user is installing your application to use, then your code would
include your consumer key.

If a user is downloading your open source code to use for their own app,
then they need to get their own consumer key to relate to their app.


Sent from my DROID

On Jan 18, 2010 2:18 PM, "M. Edward (Ed) Borasky" <> wrote:

OK ... let me make *sure* I understand this. Is this the "best

1. I write a desktop application. Whether it's closed or open source
is irrelevant. I advertise this application for sale, saying, "It runs
on Windows, Macintosh and Linux desktops (KDE, Gnome, XFCE, let's
say), it does all these wonderful things, *and* it's oAuth-secure!"

2. I *sell* Bob a copy of my application. It contains code but *no*
oAuth tokens of any kind.

3. Bob installs the application. Bob starts up the application.

4. The application starts up the browser and points it to, and directs Bob to do the following:
   4.a. Log in to Twitter.
   4.b. Fill in the form. I tried this with a dummy application, and
the Application Name must be *unique*. So what does Bob put in this
field? "Bob's copy of Ed's wonderful application?"
   4.c. Now Bob has a consumer key and consumer secret, unique to
*his* copy of the application, *not* generic to the application.

5. The application instructs him to enter the freshly-minted consumer
key and secret via copy and paste into a dialog box, checks them for
validity against the Twitter oAuth servers, and then stores them
someplace that an attacker can't find them. This is, of course,
platform dependent - the application needs special code for Windows,
Mac, and at least two Linux desktops. See
for the application's responsibilities in this area.

6. OK, now Bob has "registered the application with Twitter". He
actually wants to use it now. The application starts up, picks up the
stored consumer key and secret, starts up the browser again, and goes
to the PIN-generation site. If Bob hasn't logged in to Twitter yet,
that site will ask him to do so. Bob gets his PIN and copies it into a
dialog box. The application does its thing, and Bob tweets about how
wonderful it is that he can do all this stuff with Ed's wonderful
application. I sell 3,000 copies of it, hire a support engineer, and
make the front page of Mashable! ;-) But there's two ways I can go
with this:
  6.a. Grant Bob indefinite permission by getting the PIN once and
storing the resulting tokens on his machine, again "someplace that an
attacker can't find them."
  6.b. Require Bob to get a new PIN each time he uses the

What's the "best practice" here? Personally, I'm leaning towards a new
PIN each time as long as it isn't an impact to Twitter servers,
because it exposes one less place for an attack.

M. Edward (Ed) Borasky

"A mathematician is a device for turning coffee into theorems." ~ Paul

Reply via email to