Interesting idea.

On Jun 11, 6: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=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

Reply via email to