Some background for those that think “Single Sign On” (or SSO) sounds like a new dating site – SSO is the option to sign into a website using an existing account on another site (eg: facebook/twitter/google+), which to the user ends up looking like “OMG MAGIC! I suddenly have a new account on this site and I didn’t have to do anything”. From the developer side you’re basically standing on the shoulders of developers that are probably way better at implementing sign on systems then you are.
The biggest problem developers have with NOT using a SSO is drop off, the more you ask for the easier it is for a user to think it’s taking too long and they want to do something else. The number of new users grows exponentially when you use SSO. Flickr’s experience with adding SSO equalled 25% increase in new users.
However, when you don’t start with SSO or if you can’t properly detect existing accounts when you implement SSO you might freak people out and result in duplicate accounts. That sucks.
The best part for users: skip the sign up flow, automatically pull in user’s avatar/name/etc to make the experience rich, ability to share what the user is doing but also pull in that user’s friends to grow your site by publishing their activity.
A few days after this panel I was talking with someone about signing up for spotify, their biggest concern with using SSO was security. I found this interesting and started a great discussion as the security of a user’s data is much higher when using SSO. FB/Twitter/G+ have entire teams that ensure not only security of user data but security to make sure the user’s accounts aren’t hacked. Then there’s another issue of permissions which I’ll get into in a moment.
From a user’s perspective the expectation of privacy changes based on which SSO the site utilizes – the amount of data Twitter holds and the ease in which that info can change is completely different than utilizing Facebook. There are also different uses for each SSO provider – You as a user might only use your gmail and facebook accounts for personal uses but use Twitter for business so you only want to associate your Instagram account with FB/G+ but not Twitter – for those St. Patty’s day parties in which you instagram your friends doing silly things like this:
Users and developers both want conveniece and control of permissions, all three systems have very different permissions. Twitter has access to data yes/no and read vs right. Facebook gives a lot more info but the user can say I want to give you this but not that you can read who my friends are but you cant post to my wall or you can post to my wall but only this once or if it’s the fifth Tuesday of a leap year and the user has to read a form and accept it (whether they do or not is an issue for another blog).
The issues of permissions are, and very well should be, in the control of the user. Developers understand they should not hold more user data than they need, the more you ask for the less users will want to utilize a site. Moreover the more user data you hold the higher your security systems need to be and the more attractive you are to get hacked. The data that gets shared back to the source of SSO is only the sharing, which brings me back to the conversation I had about signing up for Spotify. Just because you’re buying Spotify Premium does not mean that Facebook can now access your credit card information.
In the end users trust the big three social networks more the more they are educated that the social networks are responsible for protecting your identity.
Oh, and to answer the question, why does it suck so often: it sucks because the developers are still navigating the fringe cases. Every site that’s using it are doing some things are awesome and some things aren’t so awesome. It sucks so often because it’s still new and emerging – but that’s why we’re at SXSW right?.
