When to Use Facebook Connect – Twitter Oauth – Google Friend Connect for Authentication?
One of the topics that came up in my post Mobile Internet Apple Facebook was around open vs. closed platforms. This issue comes up at the start of almost every new startup company in a variety of forms. I’m constantly struggling with trying to figure out the best way to pull together solutions, especially with how fast things move. In this post, I want to look at just the question of when it makes sense to use Facebook Connect, Twitter Oauth, OpenID, Yahoo Browser-Based Authentication, Google Friend Connect or basically any of the other authentication mechanisms.
Example
What do I mean? Here’s the block that you see when you look at a blog enabled by Disqus (a third party commenting tool that can be embedded in blogs and other content):
It allows you to authenticate yourself using Facebook Connect, Twitter Oauth (sign in with Twitter), OpenID, and Yahoo Browser-Based Authentication. If you have an account on any of those systems, you can click the relevant button. From there, you will generally see a pop-up dialog similar to the following (this one is from CitySearch):
Once you click Connect, the original site now knows that I’m Tony Karrer from Facebook and the various demographic and friend information from Facebook. That’s it. No registration on Disqus required. Instead, I’m telling it to use my Facebook account as my registration.
In the case of Disqus, they also allow for comments as a Guest. Interestingly, they are not including Google Authentication. Of course, you have to draw the line somewhere. How many Authorizations (single sign-on) systems do you need to implement? More on this below.
Value of Third Party Authentication
Why provide all of these authentication options?
- It makes it easier for users to transact with the system. They don’t have to go through a registration process. In the case of Disqus, you can leave a comment pretty easily which increases the likelihood of the action.
- In case the person isn’t on Facebook, then you want to provide other choices. In the case of Disqus, they’ve provided quite a few – but still have left out others like Google. Providing more choices increases the chances that your audience will be able to use one of these to authenticate.
- If the person isn’t a member of any of these or doesn’t want your site to know about them on these social sites, then you still need your own authentication mechanism. In the case of Disqus, they allow for posting by a Guest. Actually, the blogger has the choice whether to allow this as they might get more spam. Bloggers may require users to register on Disqus to reduce spam.
- By having someone authenticate on Facebook or Twitter, you are also asking for permission to do things on that site on their behalf. In other words, the application often requests permission to tweet or publish content to your wall. Obviously, the goal is to get viral spread through these actions – and to facilitate value for users.
For something like commenting on a blog post, the ability to easily and quickly authenticate yourself is important. The fact that Disqus provides a means for me to authenticate quickly and easily using Facebook Connect or Twitter Oauth is great stuff and definitely increases the likelihood that I’ll leave a comment. I’m less likely to leave a comment if there’s an annoying registration process.
And because it’s so easy, if I’m a blogger and concerned about spam, I might very well turn off comments by Guests.
So in the case of Disqus, it likely makes a lot of sense to have implemented third party authentication.
Does it Make Sense for Other Startups?
Let’s look at what commonly is the conversation with each new startup (and again I’m going to just focus on the authentication portion).
Wouldn’t it be nice if users could register on our site using these same mechanisms?
The same value proposition applies. If your user base happens to be heavily from these social sites, then it will reduce the effort for users to get registered on our site. And every startup believes that the viral possibilities are big – isn’t everyone going to tweet what they are doing on our site?
But let’s look at it a little more closely …
Multiple Authentication Authorities
There’s cost associated with each authentication authority that you are willing to accept. Each one takes a little bit to get wired. And as Disqus just experienced, you may run into bugs that cause that authority not to work for periods of time (I believe they were down with Facebook Connect for a week – ouch).
You also have a weird issue that you can’t tie the user to multiple authorities at one time. Each one acts independently. You may have experienced this yourself. You come back to a site you’ve used before. It no longer recognizes you (cookie has expired or been deleted). And it presents you with the same choices. However, if you can’t remember which authority you used and you choose a different one, then it won’t recognize you as a returning user.
The only way around this is for the application to ask you to login to each of the authorities at the start. You sometimes see this when systems want to be able to send tweets and publish to your Wall.
Think this doesn’t happen – well I’ve run into it several times myself. I couldn’t figure out why twitterfeed was sending out tweets of my blog posts. I would log into the system and it didn’t show me that feed. I later realized that I had two logins. I had originally authenticated myself using OpenID. Later, I created another account by directly registering. I wasn’t seeing the feed because the system had no idea I had two accounts (and I had forgot).
In the case of Disqus, it’s not quite as bad because they basically are using it to derive a name and picture that goes along with the comment. However, when Facebook Connect authentication wasn’t working and I choose to have the system get my name via Twitter Oauth, then the system thinks that’s two different people named Tony Karrer. And you can see two different profiles with different sets of content.
Again, I think it makes sense for Disqus – but this complexity may make the simplest form of third party authentication not make sense for most startups.
Email Address
Almost every startup wants and needs email as a means of notifying users. Take a look at Startup Metrics. A lot of value is derived through being able to reach out in order to convert, retain, refer, etc. I need to do another post that looks purely at notification mechanisms – especially alternatives like direct tweets, Facebook messages, etc. In the meantime, I will say that most startups will want to have an email address for users. For good reason, twitter, Facebook, etc. do not provide access to the email address.
Thus, what you often see is a request for the email address as part of the registration on top of making the Facebook Connect request. I don’t have the numbers on it, but my guess is that this both hurts registration percentages (you’ve just added a hurdle) and likely gets you a lot of bogus email addresses. You can roundtrip the email, but that puts up another hurdle and gets you farther from the immediacy you were going for.
As an example (and coming out of the comments), here's what Going.com does as after you validate with FB Connect:
FB provides and thus Going auto fills:
- Name
- Picture
- Gender
They need to ask for:
- Email address
- Password
- Permission to send email
There's a bit of a thorny issue about auto filling. FB's policy is that you cannot store that data.
Bottom Line
This is a post that I’m hoping there will be people who will debate the value proposition with me. Right now, here’s how I summarize it …
For most startups, I’m not going to use third party authentication as the primary authentication mechanism. It’s too risky and problematic.
Instead, I may use third party authentication to get the registration process started. That means that I’ll get a name, picture, some demographic data and permissions on the social site. But I’ll still capture email and establish a separate password.
There’s cost for each of the authentication mechanisms, is it worth it?
- Do I believe I’ll get more registrants?
- How well will I get publishing/viral behavior with third party authentication as compared to a Share button?
- Would the demographic data be valuable?
- Would friend information be valuable?
- Is there a particular kind of messaging on the social site that’s needed?
- Do I strongly believe that inviting friends is going to work well?
Depending on these answers, I may decide that I’ll do it.
Resources
Here are some related articles:
- The Social Network Wars Begin In Earnest: Facebook Bans Google Friend Connect
- Update once to share with many on Yahoo! and Facebook
- Facebook Connect vs. Sign in with Twitter: Fight!
- The 10 Commandments of Facebook Connect
- 10 Impressive New Implementations of Facebook Connect
- Is the web establishment overlooking the opportunities of the open social web?
- Identity Wars: Google & Yahoo! Bow to Facebook & Twitter
- How to Add Facebook Connect to Your Blog in 8 Minutes
- What's Going On with OAuth?
Love to hear your thoughts on this.
21 comments:
Carsten - thanks for the input. Good suggestion to always ask if they are a returning user. You then shift to helping them to identify the SAME authentication source. Obviously, you can prompt for something like the name to help with that.
Essentially you and I land on the same thing - you still need to associate another login with the account.
But I don't believe it can be "at any time" - you need it fairly early in case the user doesn't come back for a while and forgets.
My understanding is that most of the Open ID providers are not currently transferring emails. Is that not true?
I've read that FB Connect will provide it - but hadn't seen that particular article.
Thanks again. Helpful comments.
Every time we look at whether to add one of these third-party login systems to SureToMeet we decide against it. It wouldn't help event organizers because they frequently create their account using an organization-specific e-mail address (e.g., events@myorg.org).
The e-mail addressees of members and prospects that invitations are sent to are frequently different from both the personal e-mail addresses those people use on Facebook and Twitter, and different from the business e-mail addresses used on LinkedIn.
For example, a few major corporations use SureToMeet for internal project meetings and cross-department activities. Some of these same people have later used different e-mail addresses for organizing casual personal activities.
I think two forces will motivate the majority of users to not use third-party logins. One is their natural desire for privacy (i.e., keeping their LinkedIn contacts separate from their Facebook friends). The other is the increased enforcement by corporations of only business use of business e-mail addresses, which has its own set of privacy issues as well.
So, while I like the concept of these third-party login systems -- I've created profiles with all of them -- I don't actually use them often because they don't express the profile appropriate for the site I'm logging into.
My partner and I have been looking at the same issue for the niche social platform we are building. We are new to most of this. Is it possible to use facebook connect to just populate the fields that you want answers to (and they dont want to fill out) and then collect that information for back end revenue generating purposes? When I signed up for going.com using facebook connect it populated my facebook interests into their "Interests" field and saved them. It then found others that have similar interests on the site. (Im not sure if they used facebook connect as well). I am wondering if they are able to use that data when they sell ad space or for their event advertising model. Chris Brogan and others have highlighted that it might not be beneficial to use facebook connect if your revenue source is going to be advertising. Foursquare seems to do what you mentioned in your email section, by asking for an email address after pressing the facebook connect button. Can you simply use facebook connect for generating a picture, name, and age?
Cliff - it's very interesting to hear you say that. I get the fact that since you have clients who essentially share a login/ID, it won't work on the admin side.
However, I'd think on the user side you might be a case where it does make sense. Fast registration. Possibly viral.
I'd also think that a bit deeper integration with FB might make sense - events, etc.
But I've really not thought through it that much.
Brian - thanks for stopping by and commenting. I've updated the post based on your comment and questions. Take a look back at the post for more on what Going.com is doing.
The short answer is that you can use FB Connect to get back name, picture and demographic data. You would still have to create your own user information and authentication mechanism that's a piggy-back on top of them. I.e., still ask for email/password. But using FB connect you wouldn't have to ask for all that other information and would be able to publish to their wall.
In terms of value for advertising - yes it provides demographic data that might be interesting to use to target ads. However, in the short-run, you probably aren't doing anything that sophisticated with advertising to make it have value.
I have no idea what you mean about Chris Brogan and FB Connect and advertising. Maybe he meant FB Apps? Can you clairfy?
Also, let me know if I've answered your question.
Thank You Tony. Yes you answered my question about auto filling. Forgive me for not clarifying Chris Brogan's statements. I dont want to misquote him. Here is the article I was referencing. http://www.chrisbrogan.com/how-facebook-connect-points-the-way-towards-velvet-rope-networks/.
We also talked to another established social network that uses facebook connect because it makes it easier for users to sign up. However, They said "Facebook does limit the amount of data that you're allowed to collect so if you're trying to make money via advertising there's definitely a downfall."
Chris Brogan is talking about a different use of FB Connect. He tells us "You don’t get a database of users. You don’t get a way to message people participating in your event, except for “in stream,” the way everyone else is using the app. You don’t have any sense of demographics, nor any control abilities to block trolls or other unwanted types."
That's true for some examples of how people are using FB connect. It's a bit like how people use Disqus. If they do everything for you, it's easy, but you don't really have your own users, any way to message them, etc.
In the case of Going.com and what I'm suggesting in my post, you are creating your own user. You can take advantage of FB information and then add your own. Any FB specific actions - you don't own that data. But if they act on your site, then you do own the data.
The TOS for Facebook Connect limits storing information that you've obtained about a user to 24 hours.
Again, I'm not fully understanding what this other social network is saying.
For your use case - grabbing picture, name, etc. is probably not a bad way to ease people into it. And if you have the concept of lurkers or people who do only lesser activities, then it might make more sense.
Thanks Tony. I think I understand clearly now. There are some sites that use full integration of Facebook connect and require no extra registration info. The only thing that comes up is the " Allow Facebook Access" prompt. I believe that the social network I quoted does it that way.
When you said what you would do to get the registration process started, I'm assuming that you are also saying that I can get as little information as I want from FB Connect (just a name,picture,& permissions)but have them fill out all other demographic data I want.
The part that I still have a little confusion on is the storing of info for only 24 hours. So lets say we collect only the name, picture, and permission to post on their wall, but we ask all other demographic info on our own form. We cant store or access the facebook generated info (Be able to send a weekly email using a users name in the greeting), but it is available when the user logs in?
It seems that what you are saying is we can let Facebook authenticate the less meaningful information while asking for and storing the more meaningful data for potential revenue sources if the community agrees to those methods (data mining, lead Generation,general advertising).
Brian - great questions and this is exactly the kinds of conversations that sparked this post. I'm thankful for the example and clarifications from you.
The 24 hour rule is that Facebook only allows a site to store personal data that it hands off for 24 hours. The user should be able to decide to turn off access to your site (from FB) and then you can't get that data anymore.
If you get the picture and name via Facebook, you can't store it for more than 24 hours. After that you have to ask FB for it again.
If you collect data on your own, e.g., ask them for an email address, then that's your data, not FB's data. You are allowed to store that and use it.
My belief is that there are a lot of sites that will pull it across and then ask the user to edit it on their site so that it can be stored locally. This is a bit murky and I believe that FB would consider this a violation. Love to hear anyone who knows about this?
So you have to be careful about what you will ask from the user. Even if FB offered you an email address, you probably would want to grab it separately so that you clearly own it and so that it can be used to look them up at a later time.
For what I believe you are describing - emailing the user at a later time - you definitely need to own the email address. The 24 hour limit would be a problem.
I'm planning to talk about notifications in another post sometime soon.
I always get annoyed when I get asked to enter a password after connecting with Twitter or Facebook. Not only does it mean more work for me but most people are going to use a weak password that will be easy to guess.
I agree that it's annoying to have to do that next step - like you do with Group.com - but it's risky not to put your users through that step.
Love to hear the solution.
I don't think there is a solution. Just tradeoffs. For short term downtime of the third-party authenticators you can really only push them to improve their infrastructure. For long term worries of third-parties disappearing collecting users emails is probably the easiest solution.
I'm not sure a whole lot of sites are willing to have a significant percentage of their users unable to login for any length of time. That said, I also don't know that the recent issues with Disqus are a good indicator.
Thanks Tony. Since we cant store the picture and name after 24 hours, does that mean other users cant see the picture and name of a Facebook Connect user unless they are logged in?
In addition to that last question, this page seems to suggest that there are things you can store indefinitely, like the picture and name. http://wiki.developers.facebook.com/index.php/Storable_Data
Brian - you can store IDs which can then be used to go back and get the information you want - name, Image URL. I don't believe that's what most implementations are doing.
I'm pretty sure there are lots of implementations on top of FB connect that keep that data around even though it violates the TOS.
Very useful conversation Tony. Your last comment states that you can store IDs which can then be used to go back and get the information you want - name, Image URL. OK
What I am trying to understand is that: if you want to show the profile picture of a FB connect user on your website say 48 hours after that user last logged into your website... e.g. he left a comment and another user looks at the page and a profile picture is needed for the page... can we just use the ID to take that picture or can we only grab that picture when that particular user is logged in? (and we need the off line extended permission to do this?)
Sorry for all these FB connect questions but you certainly know 1000 times more about it than we do! Thanks!
Kevin - you can use the Fb:photo with the stored ID.
The list of allowed storable IDs include the photo ID (PID).
So, pictures are easy enough to grab (although overhead is a bit unknown).
Thanks Tony.
The info shared here is a bit out of date which should change the recommendations.
Last April, Facebook relaxed the data storage policies for 3rd parties and we can now store data beyond 24 hours (http://www.insidefacebook.com/2010/04/21/facebook-removing-24-hour-caching-policy-on-user-data-for-developers/).
Additionally, you can request the email address during your FB connect authorization request which means that sites/services shouldn't have to separately ask for email address as referenced in the blog post.
However, what is still true, is whether or not you want to take a deep dependency on Facebook. They may change their policies again in the future.
"In the case of Disqus, you can leave a comment pretty easily which increases the likelihood of the action." - This increase the number of spammers very easily who spam others website for the sack of SEO. Nice that Google lets Panda and Penguin to work on.
Post a Comment