Skip to content

Twilver authentication model

by Brandon on May 25th, 2009

I had some questions in the comments about how I built Twilver, so here’s a quick overview of how the app works.  Of course this is still “prototype” territory so it could change entirely in the future, especially if you have better ideas!

Anyway, the current build works like this:

First, you browse to which is an Azure ASP .NET page hosting the Twilver Silverlight 3.0 control.  The control checks to see if it has a cached access token, and since it’s your first visit, it does not.  It then redirects the hosting web page to Twitter and makes a call via the OAuth API.  Then you log into Twitter directly so only they see your credentials, and they give back an authorized token to my ASP .NET service on Azure, via the OAuth callback registration.

After that my service exchanges the auth token for an Access Token and Access Secret, which are provided by Twitter and don’t expire unless the user goes to Twitter and revoke’s my app’s authorization.

The web page passes the Access Token and Secret to the Silverlight control, which stores them in local isolated storage.  Then when the Silverlight control wants to make a request to Twitter, it calls into my proxy WCF service running on the Azure server.  This is necessary (I think), because Twitter doesn’t register their API for cross-domain access by Silverlight and Flash.  So Silverlight prevents me from making a direct cross-domain call.  My proxy service is a very, very simple WCF wrapper around the Twitter API.  Building this in Visual Studio was dead simple.

In the future I could change it so that the access token and secret aren’t stored in the Silverlight local storage, but instead are stored by my service in the Azure storage service.  For now, having the control do the caching seemed simplest, as it means my service is stateless and doesn’t track anything at all about users.  I may want to change that any way in the future, though, so that I could offer features like roaming settings and such.

So that’s what I put together this weekend.  Any feedback or suggestions would be more than appreciated!

From → Technology

One Comment
  1. Well done man. looking forward to its evolution. will love a more in depth post on how you made the app later. but this post does gives out all of the general view of development it took.

    I do think that storing it in Azure would make it even simpler for you or it is worth the try. that is the good thing about Silverlight and Azure. you can change things around and the app is updated whether is OOB or not.

Leave a Reply

Note: XHTML is allowed. Your email address will never be published.

Subscribe to this comment feed via RSS