

Ask HN: OAuth, what to use? Fb, Twitter, g+? How does that impact conversion? - allbombs

Earlier this morning I saw the Social API that supports all three variations (http://news.ycombinator.com/item?id=4669866) but it's not flexible enough for my project (I want to create a fb application and opt users in during registration).<p>Instead of invading that thread, and potentially derailing any of their efforts (I think it's cool, but wont work for me), I started my own thread.<p>My question has 2 parts.&#60;p&#62;Has anyone spent a significant time researching/analyzing each of the networks (fb, tw) to weigh the pros and cons of each network. I tried to quickly search HN but was unable to find anything relevant =(<p>Most startups support one network to start, and then offer multiple oauth networks during registration.&#60;p&#62;I'm trying to locate blog posts, videos, or threads where people discuss pros/cons of registration with each network, the implications of social sharing for each network, and corresponding conversion rates. I suppose there's registration, then social registration (tell/invite your friends), then the actual social sharing of what activities people complete within your application/service. I understand these questions are highly dependent on the type of service(s) and your overall goals/strategy.<p>Thanks!!
======
bmelton
In one of my apps, which is highly targeted towards Enterprise IT types, we're
using LinkedIn and Google exclusively.

In another app I'm writing, I'm only implementing Github oAuth (as it's
closely tied in to Github).

In the past, I've written apps that implemented any or all of the usuals,
Google, Twitter, Facebook, Yahoo, Foursquare, Dropbox, Flickr, Instagram and
(not oAuth, but) OpenID.

In my experience, it really depends on what you're building. The first site I
mentioned leans towards LinkedIn. More consumer-oriented sites lean towards
Facebook/Twitter, followed closely by native auth.

I once had a Flickr-tools site (long-since shuttered), obviously, Flickr oAuth
dominated that site.

If you're building a Facebook app, my guess is that the majority of your users
will be Facebook users, so I wouldn't bother to implement anything other than
that. If it's an app that will be embedded into Facebook, then your decision's
already made, as you can practically inherit logins from Facebook users. If
you're planning to serve apps outside of Facebook, then also make sure you're
doing native auth.

Offtopic slightly, what about dailycred didn't work with your site? In all of
the applications I've built, I've only used one auth login library,
<https://github.com/omab/django-social-auth> (except for the Flickr site,
which wasn't Django.) If you have something like dailycred not working, you
might need to reconsider how you're structuring your data.

The typical implementation pattern is to have User objects (like you'd have if
they performed a native auth), and various authentication types that all
resolve into the singular User object. Users can authenticate via whatever
they want, but only one 'account' exists for them, such that you can attach
multiple authentication providers to the same user. FWIW, dailycred does this,
and attempts to automatically reconcile (by email I believe) users who might
use Twitter to log in today, and Google to log in tomorrow, but are otherwise
the same user.

~~~
allbombs
Thanks for the detailed response. How did you find linkedin? I have some
friends that used that oauth method and it wasn't as social as say fb or
twitter. Would love to hear any comments on how those networks performed for
your projects

~~~
bmelton
Re: LinkedIn

Integration for it was easy enough, though I have the slight complaint that
they don't give me the user's email address as part of the oAuth process, and
I can't even get it with an additional request. Since we're automatically
reconciling user accounts based on authenticated emails, this makes LinkedIn
kind of the odd man out.

As far as traction, LinkedIn represents approximately 30-35% of our users who
are authenticating via oAuth, which is only about about 32% of total users.
So, one out of three users logs in with oAuth (vs. traditional
username/password auth), and of those, 2 out of three prefer Google to
LinkedIn -- and this is on our Enterprisey product.

In other side projects, LinkedIn usage is far less. Perhaps one out of 15
users prefer it to Facebook / Google / Twitter, and it's probably worth noting
that in the consumer-based apps (games and the like), users prefer oAuth 3 to
1.

