There has been a lot of blog recently about web properties adopting a Single Sign In policy. In Single Sign In, users can register and authenticate with a site by using their credentials for an identity of theirs on another site. The new site doesn’t get to see the credentials, they just have to trust the old site when it notifies the new site that the authentication was correct. In that way, less popular sites use the most popular sites as an authentication provider.
Right now, the most popular authentication providers are Facebook, Google, and Yahoo. The most popular technologies that web sites use for authentication purposes is Facebook Connect and OpenID. Under the covers, Facebook Connect uses their FBML or Face Book Markup Language technology to retrieve information about the authenticating user. Google very recently announced their Google Friend Connect technology which acts as a gateway to authenticate using your Google, Yahoo, AOL Instant Messenger, or any OpenID account. Under the covers, Google Friend Connect uses the OpenSocial technology to retrieve information about the authenticating user. The default data that you can expect to get is display name and avatar thumbnail image. What you will never get is the email address of the authenticating user.
Although use of Single Sign In has definitely gained traction amongst many User Generated Content sites, I have noticed quite some push back in the circles that I frequently travel in. In a recent interview on Second Life with Information Week’s Mitch Wagner, he was asked about his opinion of Single Sign In and he said that he is against using it.
There are two big disadvantages to adopting Single Sign In. The biggest disadvantage is that you don’t get an email address for the new user. This means that you can’t leverage this registration as a revenue stream where you sell mailing lists to spam companies. This practice is now euphemistically termed sponsorships. Obviously, this is a disadvantage for the hosting organization and not the registering user. The other disadvantage is that you are dependent on a third party vendor with which you have no legally binding agreement. If Facebook or Google shut down these APIs tomorrow, then you would lose that percentage of your user base overnight.
There are also some big advantages to adopting Single Sign In. It lowers the barrier to participation. People are hesitant to provide such private information as email address to web properties that they have not established sufficient trust with. Obviously, you could set up an email account for just that purpose but not everyone is that clever or wishes to go to that much trouble. If you can register and gain the benefits of membership without having to provide an email address, then you are more likely to participate.
People who are socially active online tend to have a lot of accounts on different web properties. From a security perspective, you are supposed to use different credentials with each account. It is near impossible to memorize what could easily be dozens to hundreds of different user ids and passwords. Yes, you could purchase or obtain a password manager tool but those come with problems too such as encryption and mobile access. With Single Sign In, you mitigate this problem by reducing the number of credentials whose user ids and passwords you have to remember.
I believe that mass adoption and use of Single Sign In could naturally lead to a federated profile in the future. Every social site has a profile page where you affect your online identity there. Wouldn’t it be great if you only had to keep one profile up to date for all of those different sites? Not only would a federated profile be easier to maintain, it would also have a greater perceived value that users would adjust their online behavior in order to keep their record clean. I believe that a federated profile would go a long way towards reducing bad behavior online.
Allow me to offer what we did here as a solution to Single Sign In. We have a product, called Cogenuity, which is a challenge based social collective intelligence platform. We sell licenses to the product where companies can self host their own instance of Cogenuity behind the firewall and that version has no Single Sign In capability. What you see online is the community edition where folks can go and share advice in a public forum. Here is how we added Single Sign In to the community edition of Cogenuity.
There is no mention of Single Sign In on the guest home page whose primary goal is to register and whose secondary goal is to learn more. The content on this site is available to anonymous access but when you try edit anything, you are redirected to the sign in page. There are also links to the sign in page on the guest home page. That sign in page has a primary goal of signing in and two secondary goals of registering or using Single Sign In. Links from the sign in page permit you to use either Google Friend Connect or Facebook Connect to register or sign in. What happens under the covers is that a local account is created for you at that point. Afterwards, you can continue to use Single Sign In or you can use the credentials for the local account to authenticate. It is hoped that, over time, the user will establish enough trust to fill out their local copy of their profile including email address.
Though not a silver bullet nor even desirable for every web property. Single Sign In does mitigate many problems with social media and UGC. There are prudent ways to mitigate the problems of Single Sign In while leveraging its benefits.