To continue my series in talking about oAuth I am now moving to one of the most critical aspects of any oAuth application: persistence. There is no value in oAuth unless you can automatically authenticate the user without asking them to allow you access to their profile. This is the core feature of Twitter and Facebook apps on mobile devices, since you dont want to allow the application every time. I will admit that getting this to work with DotNetOpenAuth was surprisingly very difficult and in the end required what I consider a bit of a hack. But lets walk through the basics of this approach.
The oAuth Dance
The first thing to understand is the oAuth dance whereby we gain the users trust. This is the process of authorization and must be done to confirm the user is ok with us accessing the service to which they belong. In our example, we are using foursquare. Once this authorization takes place you will receive an access token and access secret from the service. Storing these allows you to make authenticated requests now and in the future without asking for authorization. This article does not deal with the expiration of these tokens.
In DotNetOpenAuth we use a WebConsumer to carry out the requests over the oAuth service line. This requires service endpoints and a ConsumerSecret and ConsumerKey which is provided by the service so as to indentify the application. You can then use these to get the authenticated token as noted above.
Disclaimer: This application is a proof of concept and does not follow proper coding standards, do not use this code in a production setting.
So our application uses a local SQL Express database to store a simple username and password with the related foursquare data stored in a separate table linked by a foreign key. An Entity Framework layer sits on top of this and allows us to extract these values based on the login and make authorized requests to the foursquare service without the user needing to do anything.
The chunk of code which allows this to happen is here:
Line 11 is most critical. You see, DotNotOpenAuth creates this concept of a TokenManager which contains the token/secret combinations for the user to access authorized data. This is a very ugly implementation and is not something you would use in production.
To clarify, there are two sets of credentials involved: the set identifying the application (ConsumerKey, ConsumerSecret) and the set proving authorization to the service (AccessKey(token) and AccessSecret).
For the application, if the user does not exist in the database they are given a message stating the login is invalid. If they have a user account but have not provided foursquare credentials we redirect them to foursquare for authorization. This part was especially hairy. I use a second page to handle the callback, though the page is never visible just does a redirect. The idea is we want to save the access information so we can use it when they log in again.
With the foursquare information saved we redirect back to our main application and present the user with the interface for access the various services provided by foursquare. The following code chunk is an example of calling the users checkin history and displaying it in a Repeater:
Ahh the beauty of Linq to XML and how deliciously evil it makes parsing XML. Granted foursquare does also support JSON which I intend to look at later.
To conclude, oAuth is quite interesting in the way it handles authentication. Still in need of some fine tuning before I can take this to the level needed to support the application I am planning to write. For one thing I would like to encapsulate a lot of the piping for parsing data and the plumbing for the connection and storage of credentials.