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.
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
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.
Comments
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.
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
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.