Cibrax (Pablo M Cibrano) - has supplied an example WCF Provider sample, including a generic Request Interceptor suitable for OAuth enabling your own RESTful WCF services.

The code is available in these two new projects (as part of the DevDefined.OAuth library).

• DevDefined.OAuth.Wcf
• ExampleOAuthChanel
  

The implementation has been covered on his blog here in a couple of posts:

• OAuth Channel for WCF Restful Services.
• Using the WCF OAuth Channel with ADO.Net service.

Thanks for the contribution Cibrax - much appreciated!

Take a look at the devdefined-tools site for more details on this library, and for those who are curious this code is all released under the MIT license.

I've had some requests from different ASP.Net developers writing applications for the OpenSocial platform lately wanting to use DevDefined.OAuth to validate signed requests with a public certificate - so I've put together a little example to help get people started.

What are we trying to do?

So first of let's review how the process works and what we're trying to achieve.



Basically as a developer for the OpenSocial platform you will be writing gadgets - these gadgets are generally defined in an XML document providing information about your application and a chunk of html content which will be rendered into an IFrame to kick the application off (including javascript functions etc. to fetch remote content) - to work around spoofing issues and to avoid cross-scripting issues your gadget can use pre-canned functions in the open-social java-script library to make requests to your own services, which to the developer appear to be a direct request to their site.

Under the hood the the requests are instead made to the opensocial host platform, which acts as a proxy passing the request onto your application - at this point the platform employes OAuth (though without any 3-pronged delegate authority being established) to sign the request using a x509 Certificate (i.e. the RSA-SHA1 signature method) at which point it calls your application with the signed request and passed on response back to the calling gadget.

The main goals in signing the request (in so far as I can tell) are to ensure it hasn't been tampered with, spoofed and provide a Nonce and timestamp so you can void replay attacks - something that using SSL alone would not prevent.

Because a lot of the mechanics of OAuth itself is being circumnavigated, it's much simpler to verify the signature is valid.

Gadget XML

Right - onto the code - Let's take a look at the Gadget XML first:


Basically the XML for the gadget is a chunk of metadata and finally some actual content for the gadget itself - notice that it regsters a handler to run on load of the gadget, and that it's then making a request to the url http://demo.devdefined.com/Friendster/SocialService.aspx and render the response in the inner HTML of the container div DOM element.

The key to this being an OAuth signed request is the 5^th line of the makeRequest function:

    params[gadgets.io.RequestParameters.AUTHORIZATION] = gadgets.io.AuthorizationType.SIGNED;

So far so good - uploading your application is pretty easy - but is generally platform specific - if you wanted to try this out on Friendster then just head to http://www.friendster.com/developer/ click on the OpenSocial tab and follow the instructions - the approach is to save your gadget definition as an XML file somewhere, then publish that XML document on the web and then create an application in your open social host of choice and direct th it to the XML files location.  It takes all of a minute to do.

ASP.Net Application (Provider)

Now for the application itself - first off you need to locate and download the provided public key (certificate) for the social platform host and either store it on the filesystem or in the case of this demo we'll just store it as a string, like so:

It's worth noting that the certificates can be changed at any time - but fair warning will be given (according to the document) - and that the location (url) of the certificate is actually included as a parameter in the requests the host makes to your application (xoauth_signature_publickey) - so it's fairly trivial to implement a caching scheme to automatically pull down and update the certificate if it has changed.

Now that we have the certificate we just need to validate the request, in this cause I'm just going to check it's been signed - I've left validating timestamps and nonces out of the example, as these tend to be propritary to the app your building, but both are easy to implement.

The process is basically using the OAuthContextBuilder class to construct a context (which is used to calculate a signature base) from the current pages request.  It then constructs a signer (used for signing requests and checking their signatures i.e. validation) and a signing context, which is used to provide additional information to the signer, such as the public key of the friendster certificate.

We then invoke ValidateSignature to ensure the signature is valid - if not we throw an exception.

Finally if an OAuthException is thrown we catch it and render it's report to response stream and close it - this provides diagnostic information as per the OAuth problem reporting extension.

Hope this has been useful to some people out there - BTW I'm no OpenSocial expert, so please direct general OpenSocial questions to the apropriate google groups, I can only help with OAuth library questions.

Problems with Friendster Requests

As a side note - for anyone who's tried writing an OpenSocial application using DevDefined.OAuth to validate request signatures they may have found it didn't work! This was a result of Friendster appending an ampersand (&) to the end of the query string on the Url, which was causing the signature base to be incorrect (I'm not sure if this is an issue for other OpenSocial implementations) - The code now checks for this and removes it if discovered - and signature validation works as expected.

You may recall a few months back I released an OAuth library for .Net (which can be found here on google code) - at the time of writing that library the only other OAuth "solution" for .Net developers was a C# file containing some simple helper functions, that didn't even produce valid results in many cases, and the rather basic implementation as part of the restful chess/myspace example.

Well the guys at Madgex in the UK have now released their own OAuth.Net library.. for more details you can:

• Check out Bruce Boughton's post on their initial release.
• Get some more details on the Madgex lab page here.
• And of course grab the code from here.

As for differences between the two implementations... from a 50K foot glance.

• There's a dependency on the Windsor container when using the Madgex library (if you want to use it's out the box implementation / configuration examples etc.)
  
• The Madgex library includes a http module for making a provider implementation easier when building web apps.
• The madgex library appears to take a harder dependency on HttpRequest then the DevDefined library (but that's just a hunch, saw it in a few interface definitions, rather then some wrapper equivalent).
  
• The madgex library looks a little more polished (i.e. xml docs) and has a configuration section.
• The Madgex library features some niceities like Sliding window validation support (i.e. they only allow messages to be supplied where the timestamp falls within a certain time window of the server, and keep the list of previous nonces only for the period of that window - flushing nonces that are not longer required via a background thread - saving on the volume of nonces to record i.e. for replay attacks).  Of course it's an in-memory solution, so not suited to farms, but still cool.
  
• Slightly less fluent consumer implementation, I prefer my libraries consumer implementation, but of course that's just me :P
• Both libraries are under the MIT license.
  

All said and done it's a very sound effort, great work guys! And it's awesome to have some choice emerging in this space.

It's been a back and forth discussion on the OAuth list for a while now - and with some people (zealots? ;o) having ideas they weren't even willing to contribute to the OAuth group until the IPR was sorted I'm glad to finally see it's been completed, this should hopefully help to improve the longevity and adoption of the standard by some who have been fence sitting.

So what's happened?

Well all all parties involved in building the original spec have signed an agreement of non-assertion, so now OAuth can be safely implemented anywhere without concern about lawsuits related to the IP in the spec.

OAuth is a pretty elementary standard in it's version 1 state - so in some ways it was inevitable that this would happen (or at least I thought so) - there wasn't much to gain by any of the contributors blocking the progress of it becoming an open standard - but it's involved a lot of work to get it there by all accounts, so full credit goes to all involved!

For a detailed writeup check out the post from Eran Hammer-Lahav or the post on Read/write web.

Conspicuous by it's absence is Microsoft, but for no other reason than they did not contribute to the OAuth standard - and so didn't have to sign - but of course LiveId does tackle delegated authentication - so in some ways they have a competing platform for handling delegation, presumably because OAuth doesn't provide a rich enough set of features at this stage to handle some of the more complex scenarios around scalability, signing message bodies etc. - though I'm just hazarding a guess, LiveId was presented at the OAuth summit earlier this year.

OAuth for Beginners

For those unfamiliar with OAuth, here's a very short run-down... I'm skipping over some of the details but I think this should give you a taste for what it's all about - for a more well rounded introduction, check out this article on the OAuth.Net website.

The participants

Consumer - "weitu.googlepages.com" - that application that wants to see protected information the provider has for a user.
Provider - "google.com" - the keeper of a users protected information.
User - a user who stores protected information with the provider (say contacts in gmail)

The goal

To allow the user to give a consumer access to their data on the provider without the user having to disclose their credentials (username & password) and to allow for fine-grained control over access granted to an individual consumer - i.e. putting power in the hands of the user to revoke access when they want to, and having it only affect one consumer.

A consumer needs to be known to a provider before they can request a token.

How it works

(For this example we'll use google, for more info on the google implementation see this thread)

The provider publishes 3 Urls for their service and documents them on their site somewhere:

• Request Token Url - https://www.google.com/accounts/OAuthGetRequestToken
• User Authorize Url - https://www.google.com/accounts/accounts/OAuthAuthorizeToken
• Access Token Url - https://www.google.com/accounts/OAuthGetAccessToken
  

The consumer is known to google by it's consumer key (which in the case of a google api is normally a host address, like www.test.com) and this relationship is established in a proprietary manor (i.e. it's not covered by the OAuth spec).

Getting a Request Token

The start the ball rolling the consumer makes a request to the Request Token Url, they get back some form-encoded parameters in the body of the response which contains the token information.

As an example, here's an http request to get a new request token:


And here's the response:


Notice the oauth_signature and other oauth_ etc. parameters - as part of the OAuth core specification it requires that requests be "signed" so that a provider can ensure they haven't been tampered with - this is one of the aspects my library will take care of for you (signing and verifying requests).

User Authorization

At that point the consumer now needs to send the user off to the providers site - this involves using the second of the 3 urls, the User Authorize Url... we just append the scope (required by google, identifies the service you wish to access - not part of OAuth spec itself) and the request token (CMiJx-LdFxD56bOXAQ)

Note that the User Authorize Url isn't signed like the other requests... this is because this step may be manual i.e. a user typing or copying a link into their browser or some hand held device.


In this case, google takes us to a universal login page:



Once authenticated it then takes us to a page where we can authorize the consumer to have access:



By granting access at this point the consumer can then use the last of the 3 Urls, the Access Token Url, to exchange their request token for an access token. Upon granting access a few things should happen:

• An access token should be created.
• The access token should be related to the request token.
• The currently logged in user should be associated with the access token.
  

The last point is important - because you're passing tokens around, rather than account names, you need to have the provider implementation record the association between the access token and the user granting access - and it should be easy for your API implementation to fetch the associated user when a protected resource is accessed.

Exchanging Tokens

Once the user has authorized the consumers access request, the consumer can then exchange their request token for an access token - generally a request token can only be used once - so if the request failed for some reason they would need to start the authorization process again from scratch.

here's the http request for exchanging tokens:


And the corresponding response from the google server:
 

Accessing a Protected Resource

Now that the consumer has an access token they can then make requests for protected resources - they just need to use the access token, here's an example of doing just that:


Obviously once the request has been validated (i.e. valid signature, valid token, valid timestamp range, nonce is unique etc.) the provider implementation needs to fetch the user associated with the access token, so it can then return the correct data back to the consumer - normally you would want to automatically associate the token's user with the current request / controller / channel so that OAuth is basically transparent (i.e. it's just like getting a request from a user who's authenticated normally).

Risks & Issues

One obvious risk is that of phishing... if the consumer sends you to a site that looks like googles authentication page, but isn't google then you're in trouble.  Of course this kind of phishing is more a general problem, then something isolated to OAuth.

Another potential risk are that some signature methods are risky/flawed to the consumer due to implementation i.e. if you have a flickr uploader winforms application, and you use RSA-SHA1, the uploader will need to ship with the x509 certificate (including the private key) in their application ... this basically invalidates the strength of that certificate, because anyone could extract and use the private key themselves (so it's as bad as a plain text signature) - on the flip side for a website RSA-SHA1 is very strong because the private key is kept private.

DevDefined.OAuth

I have a first release of my OAuth implementation up on google code, you can read a little more about it here and the code can be found here.  It's released under the MIT license, basically do what you like with it.

The library includes both consumer and a provider implementations - test coverage is pretty poor, as it was originally put together as part of my REST presentation to the local Ellerslie .Net user group a few weeks ago, but as I work through the code and rewrite various sections in my spare time it should become a little more robust.

If you're serious about using this code then I would suggest reviewing the OAuth core spec 1.0 and the OAuth problem reporting extensions.

The OAuth wiki and google group are also great places to learn more about OAuth.

I have not added the MonoRail examples back to the code yet - but will shortly - and will probably provide a WCF implementation as well.

I've also posted a short intro to OAuth - OAuth for beginners - for those who are interested.