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).
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.
My question has 2 parts.<p>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 =(
Most startups support one network to start, and then offer multiple oauth networks during registration.<p>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.
Thanks!!
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.