(E/m)^-2 =

One of the greatest improvements in online usability and user experience since the adoption of AJAX techniques that provide functionality such as Google Suggest, is the standardization of single sign-on. OpenID has been around for a long time and has helped pave the way to robust, secure 3rd party information exchange frameworks such as OAuth.

The purpose of these services is to allow sites to authenticate end users and optionally access their information such as email address, photo stream, Facebook profile, LinkedIn contacts or any other information the site may request and the user agrees to share.

For example, a few simple clicks and your visitor can sign-up to your site and provide you with a validated email address without completing yet another subscription form, without replying to yet another email confirmation message and without memorizing yet another password... All this is thanks to the fact that everyone already has an account with a large, trusted service provider such as GMail, Facebook, LinkedIn, Yahoo!, or even a Blogger account. These 3rd party service implement standardized protocols such as OpenID and OAuth to offerer decentralized, user-centric, authentication and authorization service that any site can leverage to enhance their user's experience.

Lets say your visitor is already signed into Facebook. If they are then presented with the option of signing in to your site using their Facebook account, all the user has to do is click a button to approve your site's request with Facebook. Assuming your visitor approves this access, Facebook then returns the requested information and provides you with a method to authenticate the details with Facebook directly to ensure that the visitor is who they say they are. That is, they are legitimate as far as Facebook is concerned and at a minimum they have an active Facebook account with an associated previously validate email address.

The more information you require the less inclined the user will be to approve your request. In fact, research indicates that an inverse correlation in user acceptance with information requested exists. So, unless your site provides some form of integration with the visitor's social data, then there is no need to request anything more than their email address, which is the norm.

The factor against widespread adoption of single sign-on and user information interchange has been the implementation complexity,  which has limited deployments in large part to competent system admins with above-average server-side programming capabilities. While specific implementations have become more straight forward to undertake, at the same time, there is a large amount of change occurring with the underlying standards and volumes of mostly technical literature that follow -This can make implementation at a practical level tough.

Facebook by far has done the best job implementing their solution with working examples that fit on a single page. See my Facebook Single Sign-on Example article. LinkedIn, on the other hand seems to have gone out of their way to make the process as obscure as possible. Google is somewhere in-between. While on the one hand Google is advancing standards development and providing proprietary enhancements with loads of examples and technical documentation, on they lack simple examples to facilitate practical implementations. In short, they simply offer too much choice.

Third parties are more interested in having their user data shared and embedded than they are with merely providing a free authentication service. This is why service providers such as LinkedIn make embeddeding user content easier than authenticating. Goole's OAuth implementation for example is a two step process -Approve request, share data. You have to do both. While most site admins are mainly interested in authentication and a valid email address, LinkedIn will not allow users to share it. Facebook on the other hand implements the more robust OAuth standard but permits you to do what you want - authenticate user/get email and optionally share share data.

In a nutshell, if you only want authentication/email OpenID is all you need. If you want to access user social data, OAuth is the more robust way to go. The problem is that each provider has different limitations and proprietary extensions -change is the only constant.

Deciding which technique to use depends mainly on what you require from the 3rd party service and to a lesser degree your architecture and administration capabilities and security level requirement.

My recent experience comes from implementing these authentication and authorization techniques on a service providing dynamic QR codes that I am currently designing.

I will create links to Single Sign-in Howto's for several different scenarios below:

Instructions for Single Sign-on using Facebook

Instructions for Single Sing-on with Google  

Even if only a basic level of security is required your server must somehow know that the 3rd party service provider can vouch for the identity of the user. While this can be achieved in several different ways, all of these methods require some sort of server-side administration capability. You will need to place some code on the server for example, in order to process and validate the authentication and authorization process.

Things can get complicated because it is possible to only partly implement a solution which can leave your site susceptible to spoofing attacks (bad people pretending to be a trusted 3rd party) and each provider implements things a little differently, which only adds to the complexity and odds of someone making a mistake...

Here 3rd party JavaScript APIs allow anyone that can add a <script>

tag to their site or even blog to 'authenticate' visitors and authorize their data to appear on your page.

These client side techniques simplify user data integration but make secure authentication more challenging...More on this later.