The problem here is that Twitter wants to use OAuth to identify and
block abusive applications, but the OAuth standard was not designed to
be used in that manner. Regardless of whether an application's source
code is published, the consumer secret key will always be easily
accessible in desktop and mobile applications that are distributed to
end users.

The entire idea of "best-effort" key security is deeply flawed. Any
spammer with a hex editor can trivially compromise the keys of popular
applications and use those keys to evade Twitter's abuse controls.
Even if that clear incentive didn't exist, it's likely that we would
still see malicious people compromising the keys of popular
applications just for the lulz. The security-through-obscurity model
simply doesn't work.

The OAuth standard itself clearly and explicitly says that service
providers SHOULD NOT use the consumer secret to verify the identity of
distributed applications:

"In many applications, the Consumer application will be under the
control of potentially untrusted parties. For example, if the Consumer
is a freely available desktop application, an attacker may be able to
download a copy for analysis. In such cases, attackers will be able to
recover the Consumer Secret used to authenticate the Consumer to the
Service Provider. Accordingly, Service Providers should not use the
Consumer Secret alone to verify the identity of the Consumer."

Facebook and Google Buzz both offer desktop-appropriate OAuth
authentication flows which do not require a consumer secret key and do
not require the user to go through a complicated copy/paste process.
This is not rocket science and it's not a hard problem to solve. It's
unclear to me why Twitter continues to consistently get it wrong.

It's also extremely frustrating that Twitter is still at the stage of
discussing potential solutions for open source applications when there
is only a few more weeks left before basic auth is scheduled to be
disabled. There might not be enough time to fully beta test an
implementation and get a patch into Ubuntu before the cutoff. Am I
supposed to just disable Twitter for several hundred thousand Ubuntu

Ryan Paul
Gwibber Project

On Jun 11, 3:56 pm, Taylor Singletary <>
> Hi Developers,
> As has been discussed on the list recently, OAuth and Open Source
> applications are a difficult combination because token secrets shouldn't be
> embedded in widely distributed code.
> We're pleased to announce that we've devised a solution to this problem.
> Next week, we plan to release a new extension to the Twitter API that will
> allow Open Source applications to obtain OAuth consumer keys and secrets for
> their users, without having to distribute an application secret.
> Approved Open Source client applications will have an easy to implement
> ability, through, to generate new client tokens & secrets to
> be used specifically for each new instance of the application.
> While completing the process does require the end-user to complete a few
> extra operations, we think this is a good compromise.
> The source tag on tweets published by the child applications generated with
> this approach will be a variation on the originating application's name. For
> examples, if the name of the parent application was "AdventureTweet" and the
> user's screen name was @zork, then the child application's name would be
> "AdventureTweet (zork)".
> The work flow for these applications will be something like this:
>   1. You store your API Consumer Key in your application distribution (but
> never your secret!).
>   2. A user downloads/installs/checks out your open source application and
> runs it for the first time
>   3. Your application builds a URL to our key exchange endpoint, using your
> consumer key.
> Example:
>   4. You send the user to that URL in whatever way makes sense in your
> environment.
>   5. That user will have to login using their Twitter credentials (if they
> aren't already), and then approve your application's request to replicate
> itself on the user's behalf.
>   6. The approval will require that the user agrees to our terms of service,
> as this process results in them having control of their own application
>   7. The user is presented with a string that they are asked to paste into
> your application. The string will contain ah API key and secret, in addition
> to an access token and token secret for the member: everything that's needed
> to get the user up and running in your application.
>   8. The user pastes the string into your application, which then consumes
> and stores it to begin performing API calls using OAuth.
> The string containing the keys will be x-www-form-urlencoded. To keep the
> string brief, it will contain abbreviated key names.
> An example:
> ck=KIyzzZUM7KvKYOpnst2aOw&cs=4PQk1eH4MadmzzEZ1G1KdrWHIFC1IPxv1kXZg0G3E&at=5 
> 42212-utEhFTv5GZZcc2R4w6thnApKtf1N1eKRedcFJthdeA&ats=FFdeOzzzzEwxOBWPPREd55 
> dKx7AAaI8NfpK7xnibv4Yls
> Where: "ck" - consumer key, "cs" - consumer secret, "at" - access token,
> "ats" - access token secret
> This kind of key requisition service is new to the Twitter ecosystem, and
> we're going to be closely monitoring it for abuse. Once we announce its
> availability, we'll begin taking requests for Open Source applications that
> would like to offer the feature in their application.
> We're excited to offer this solution to the open source community. Thanks
> everyone!
> Taylor Singletary
> Developer Advocate, Twitter

Reply via email to