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 dev.twitter.com, 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:
http://dev.twitter.com/apps/key_exchange?oauth_consumer_key=abcdefghijklmnopqrstuvwxyz
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=542212-utEhFTv5GZZcc2R4w6thnApKtf1N1eKRedcFJthdeA&ats=FFdeOzzzzEwxOBWPPREd55dKx7AAaI8NfpK7xnibv4Yls
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
http://twitter.com/episod
