Inhouse registration vs. OpenID vs. Google Friend Connect vs. Facebook Connect vs. (etc)

Question

I\'m trying to decide how to allow users to register for my website... there\'s openID, clickpass, facebook connect, google friend connect, etc, or the good old fashioned in-hou

Answer 1

If you will need to maintain state information about your users (preferences and such) then you probably should provide your own user/password mechanism. This does not stop you from allowing users to take advantage of OpenID and its ilk. The question you need to answer is how much time should you devote in your project to supporting more than one method. Like all design decisions, there is a cost and a benefit to everything. Weight them both and pick the answer that fits your budget.

Answer 2

Another possible option, instead of grinding the OpenID code yourself with the libraries is to use a SaaS service like RPX . You can get OpenID, facebook & myspace login in a couple hours. Your app just needs to be able to make HTTPS and parse JSON or XML resposnes.

Answer 3

It really depends on the type of site and who your users are.

We looked at the possibility of using OpenID for our e-commerce store (we sell apparel), and the conclusion was that we would be flat out nuts to implement it. I'm not the smartest software developer in the world by any means, but if I could barely wrap my mind around it enough just to get an account for StackOverflow (Why do I have to go to some third party provider? Why should I trust them? What happens to my account if they go under? As a business, what do I do if a customer asks me to reset their password?), then it's not just anecdotal to say that our customers would have problems with it. In addition, for any e-commerce business, it's usually unwise to take on a third-party dependency unless carefully considered, and especially for something as critical as logging in. If a major OpenID provider were to go down, you'd be losing sales. If we implemented OpenID, it would definitely be an alternative, red-headed step child implementation when compared to the native sign in mechanism.

Even with our in-house registration of e-mail addresses and passwords, we had to use an Amazon.com style login form because users kept filling out the "new customer" form even when they already had an account:

Login screen. Amazon's sign-in screen remains a model to be emulated, minimizing the common problem of new customers who try to log in without having registered. Amazon presents two questions in linear order: (1) "What is your email address?" and (2) "Do you have an Amazon.com password?" For the second question, users can select one of two radio buttons: "No, I am a new customer," or "Yes, I have a password." Many other sites present the new- and established-user sections side-by-side, and thereby divert new users to the established-user section through the magnetic attraction of type-in fields. -- Jakob Niesen, useit.com

When users have trouble navigating two fields and a radio button, you can imagine the hilarity that ensues when they are presented with multiple authentication mechanisms.

If you're implementing a social-oriented Web site that is designed to integrate with Facebook or some of the Web-2.0-savvy consumers, then these alternative authentication mechanisms may make sense. Until the dust settles on OpenID, though, I wouldn't add it to a commercial site: nobody has asked for it. They have asked for PayPal and Google Checkout, which we implemented, but there's only a small amount of overlap there.

My general recommendation would be to have the usual in house username and password mechanism that can be supplemented by these alternative identification mechanisms. But realize that each alternative identification mechanism runs the risk of customer confusion and increased customer support.

Just my two cents; hope that helps.

Answer 4

I am planning to do something simialr on my social network site but a little different then other sites do. Most sites allow users to login with these services, I plan to add these services to my signup form, they then pick there service, openID, facebook connect, myspace ID, then what I plan to do is get all info that these services provide and store them as a variable in my php script and then save to DB, the concept is to allow them to import info from other services on signup to make it easiar for them to signup, meaning less profile fields they will have to fill in later and such

Answer 5

Looking briefly at How to set-up OpenID it seems like a lot of work to get openID working.

It really isn't a lot of work. For a project still not even close to being public I downloaded Dope OpenID and after just a few hours (mostly spent doing CSS/HTML work which I really hate) of playing around I had a login procedure setup that looks and works like the one you see when logging in to SO.

For example.. if you allow both the in-house registration and openID, what percentage of your users are using OpenID?

Now when you can use you yahoo, AIM and GMail login as OpenIDs there is really little point in creating your own user verification and have to worry about salting hashes correct and about things like if users failing to login 3 times/second should be banned for a few minutes, restoring passwords when users have forgot about them etc.

You can of course provide an ordinary login as well but then you would still have to carry all the good stuff that OpenID lifts from your shoulders. It is not that frightening to ask the users to register gmail or yahoo account they can use, most of them probably have one already.

Answer 6

@Nicolas has some very good points.

I recommend starting with standard username/password, and add OpenID, etc. as options later if enough users ask for them (just like the Plaxo tutorial).

Its always better to have a working site now, rather than a project that gets canned at the 90% mark. :-)