Posts tagged with “oauth”

Kantter in the wild (now with even more OAuth)

Wednesday, 10 June, 2009

Today I set up a Gitorious account to host the git repository for Kantter. Feel free clone or download it, but be warned, as it  very pre-alpha quality at this stage. Comments, suggestions and/or patches are welcome (though I have a fair list of each myself). You may also want to have a look at the requirements page to get you going.

Also, in addition to yesterday’s post, Twitter have now decided to add an extra step to the OAuth process. After the User (Me) gives approval to the Service Provider (Twitter) for the Consumer (Kantter) to make authorized request, the Service Provider provides the User with a PIN to give to the Consumer which is then used to validate the user’s key/secret pair.

It is a bit annoying that they decided to make a change just after I got everything working, but fortunately it was only a small one, and was easy to add support into Kantter.

Kantter v0.2 – now with OAuth

Wednesday, 10 June, 2009

After a bit of playing around, I finally managed to get OAuth authorization working, and integrated with Kantter. The fruits of my labour can been seen below with my very first twitter status update using Kantter.

kantter v0.2

I was too lazy to actually read the documentation about how OAuth works, but I found a decent python oauth implementation, complete with an understandable example of a twitter client. From just looking at the code, this is how I’ve interpreted OAuth works:

  1. A Service Provider (Twitter) issues a Consumer (Kantter) with the consumer’s key/secret pair
  2. The Consumer (Kantter) uses the consumer’s key/secret pair to sign a request
  3. The Consumer (Kantter) then sends this signed request to the Service Provider (Twitter) to request approval to do stuff on behalf of the User (Me)
  4. The Service Provider (Twitter) then send back a key/secret pair to be associated with a User (Me)
  5. The Consumer (Kantter) prompts the User (Me) to approve the the request with the Service Provider (Twitter) using the user’s key as a reference for the request
  6. The User (Me) approves the request with the Service Provider (Twitter) – ie. logs into twitter, supplies the user key, and approves the request
  7. All further requests from the Consumer (Kantter) to the Service Provider (Twitter) are  signed by both the consumer’s key/secret pair and the user’s key/secret pair

Therefore the Service Provider (Twitter) trusts the Consumer (Kantter) based on the consumer key/secret pair. Based on this trust, the Service Provider (Twitter) issues key/secret pair to the Consumer (Kantter) to be approved for use by the User (Me) – the user’s key/secret pair is associate with both the Consumer (Kantter) and the User (Me). Finally, by having the User (Me) give approval to the Service Provider (Twitter) for the use of the user key, any request that is signed using both the consumer’s key/secret pair and the user’s pair is considered a valid request from the Consumer (Kantter) on behalf of the User (Me).

So as long as Kantter knows my key/secret pair, I can interact with Twitter without ever having to supply my credentials (or until I revoke the key/secret pair).

Unfortunately this may have some security implications if the key/secret are stored in a config file that is viewable by other people. It also means that using Kantter for multiple Twitter accounts won’t be as simple as supplying a different username/password when the application starts.

Things to consider later. For now I’m just happy that OAuth is working