use_last_segment="yes"}

Social Media and OAuth2 Integration

Nowadays it seems that every online service is harnessing the benefits of Social Media by integrating with the likes of Facebook, Twitter etc. Whether logging on using your preferred Social Media or tweeting the details of your latest purchases from Amazon, Social Media not only enhances the user experience but promotes those services that harness its power.

Securing a user’s sensitive data becomes paramount as we give our permissions for intermediary websites to access our Social Media accounts and information. It’s imperative that we don’t share our Social Media credentials with such sites and that we can control their level of access to our data.

Enter OAuth, an authentication protocol, which has become the protocol of choice for many of the Social Media platforms. OAuth2 is the latest version of the standard and the one which most Social Media platforms are adopting. OAuth is not a new concept for authentication, rather its design is based upon existing protocols such as Amazon Web Services API and Google AuthSub. Common to many of these is the mechanism by which user credentials are exchanged for some kind of access token. This token governs the communication between a client and a secured resource. With regards to OAuth2, not only does the validity of this access token determine whether a resource can be accessed but it also contains the level of scope/access the intermediary is permitted.

But OAuth2 has become more than just the de facto authentication protocol for Social Media platforms. With the rise of Restful webservices (overtaking those of Soap based webservices), a new and robust way to secure these often stateful services has arisen. OAuth2 has fulfilled this need and is increasingly being used to secure Restful services wherever they’re found.

With all this in mind a proposal for an internal R&D project was put together at RDF Group, to investigate two main themes; firstly, Java based Social Media integration and, secondly, Java based OAuth2 servers and how they could be deployed to secure bespoke Restful services. The project goal would be to implement a white-labelled web application illustrating Social Media integration i.e. logging in with preferred Social Media and performing simple use cases such as tweeting or accessing Facebook friends. In addition to this, a bespoke OAuth2 server would be created and used to secure Restful services on a separate server.

After investigating existing Java solutions for Social Media integration, Spring-Social was selected. We also considered Agorava which, although looking promising, didn’t seem mature enough for any potential client project. Spring-Social on the other hand is currently on its 1.0.3 release with good community support and good documentation. Spring-Social also provides a comprehensive suite of sample projects all available on GitHub .

Taking one of these samples as the basis for our white-labelled web application, we enhanced it by adding additional social media integration. The original sample allowed users to login with their chosen Social Media and access their user profiles. We extended this functionality by adding the ability to send a tweet or post to your Facebook wall once logged in. This was all very intuitive using Spring-Social’s API’s for the different Social platforms.

In investigating Java based OAuth2 implementations, Apache’s Oltu project (formally Apache Amber) was selected. We implemented a simple server using the Oltu API with the corresponding OAuth2 authentication services. These included services to obtain authentication codes and then to exchange these for access tokens. Apache Oltu also includes the means for retrieving an access token from a HTTP request, returning appropriate OAuth2 responses and other useful functionality.

One of the overheads of OAuth2 can be the complexity of the protocol and understanding the nuances of what’s sometimes called the ‘OAuth dance’. This is the initial hand-shake process by which a client is authenticated and an access token is obtained. This multi-stage process typically involves website users being redirected to their Social Media’s login form and then back again (with access tokens being exchanged for authorisation codes behind the scene). It’s not the intention of this blog to describe this process, rather I recommend you look at some of the existing resources out there. For a simple and concise illustration I’d recommend Aaron Parecki’s excellent blog article.

Once our OAuth2 authentication server had been implemented we then created a mock enterprise application - aka the resource server in OAuth terminology. This exposed Restful services to access a user’s profile and business contacts. We then secured these services to ensure they were only accessible with a valid access token gained after the initial OAuth hand-shake process. The access token is passed as a HTTP header property on each request to the enterprise application. The OAuth2 standard doesn’t mandate how an access token is validated by the resource server.

Some access tokens could be self-contained and, provided these were ‘short-lived’ tokens, they might contain the means to validate themselves. A more realistic scenario would be that the resource server calls back to the authentication server for validation. We therefore created such a service on our OAuth server which could be called by the enterprise application passing it a received access token to validate.

The final piece of the jigsaw was to extend Spring-Social to manage the communication between the white-labelled site, our OAuth2 server and our mock enterprise server. Spring-Social is designed to be easily extendable for any OAuth provider. Not only does it provide extension API’s for the more common Social Media platforms - Facebook, Twitter etc., but it also has many community developed extensions, for example Spring-Social-Dropbox or Spring-Social-Flickr. It was fairly intuitive to implement our own API enabling us to integrate our white-labelled app with our own OAuth2 secured enterprise application. So using one of the users created against our enterprise application, they could successfully login to our white-labelled app and accessing their business contacts and profile information.

Beyond justifying my days spent browsing Facebook and Twitter, this R&D project successfully proved some exciting technology for RDF. We now have a clear understanding of how to provide rich integration with Social Media platforms harnessing the benefits Social Media could bring to our client’s applications. In addition we can continue to promote the advantages of Restful webservices, comfortable in the knowledge that we can design robust security around them utilising the OAuth2 protocol.

comments powered by Disqus
Share |