Show HN: One OAuth API for Facebook, Twitter, Google, and Email

Could not have come at a better time, I was literally going to sit down this weekend and build a multi-provider auth for my project. Just take my money. Take it!<p>I 'get it', it's awesome. Thanks for building :)

Looks awesome. I think you should reverse your header and sub-header, though.<p>"Simple user accounts and analytics for your website" is a much clearer description than "Social Authentication Done Right."

I find it a bit misleading to have your favicon be the same as the SSL lock in Chrome: <a href="http://i.imgur.com/qnP8Q.png" rel="nofollow">http://i.imgur.com/qnP8Q.png</a>

It's a pain in the ass if they ever go down. Remember, user auth is your bread and butter, outsource it with care and not just to save a buck here and there.

I'd like to add that the DailyCred guys are incredibly warm folks to know in person - I've had the pleasure of long chats with them here in Seattle :)

Worth mentioning: this means you can add Twitter support using OAuth 2.0, instead of fighting with OAuth 1.0. That alone saves a ton of grief.

This is pretty amazing. Im dealing with this very issue on my app with devise and omniauth.<p>One thingI havent seen asked and answered is what do you do if the OAUTH provider does not supply email(which you mentioned is used to determined if the user has already signed in via a different provider).<p>For example. A user signs in via Facebook and is authenticated(his email and provider uid is stored). He then goes to a different machine/browser and signs in via Twitter which does not provide an email address neccessary to associated with a previous Facebook sign in. What then?

How does this compare/contrast with <a href="http://singly.com" rel="nofollow">http://singly.com</a>?

This looks interesting, but I had a few questions:<p>1. If I use this do I have to handle account linking? Ex: Monday user logs in with FB, Tuesday with Twitter. Do you pass a unique key saying this is a canonical "user"?<p>2. From the gem docs it looks like you're returning a hash of whatever the social provider returns and explicitly not trying to "normalize" the result (ex: One service might return "email" and another "email_address"). This seems fairly different to what happens with Devise and Janrain. Is this going to change with time or do you see this as key point of differentiation.<p>3. What happens if you guys win the lottery and all retire to a tropical island? How screwed am I with my users?

Looks great - except missing the one I need for my product: LinkedIn! any timeframe for linkedin?

So first we have APIs for handling photo uploads, so we don't have to host the photos ourselves? And now we have APIs for handling users, so we don't have to host the users ourselves?<p>Whatever API storage service is coming out next?

Wait. Does this mean I no longer need to create multiple authentication services?

Very good idea however:<p>When you provide an service like this and your website got mixed SSL content (seems like due to youtube video, so mixed only after user plays the video), it's a bit worrying.<p>Not to mention this:<p>"Use our sign in UI, and get secure authentication over https for free. Don't waste another moment buying or implementing ssl certs ($70 on GoDaddy)."<p>Which is really really bad advice. SSL is not just for authentication. Keeping auth over SSL and rest of the website over HTTP is an insecure way to implement an authentication system.

Is there a use case supporting native (iOS, Android) apps?<p>To me, the site seems to be targeted at web platforms (Which I'm considering using for a current project).

This looks incredibly useful! However, its existence raises an important question.<p>Doesn't the necessity of this product inherently suggest underlying flaws in the 0Auth 2.0 framework (not protocol)? In my mind (and Eran Hammer apparently agrees), one major shortcoming of OAuth 2.0 is that the specification all but ensures that a universal, drop-in library for an arbitrary implementation of OAuth 2.0 <i>cannot</i> exist.<p>We saw this problem with OpenID - we even had a service designed around 'solving' the problem of integrating multiple OpenID providers. If the framework itself is so complicated that it needs extra abstraction layers to simplify it for basic, general use, to me, that suggests design flaws.<p><i>EDIT</i>: On re-reading Hammer's post[1], I've realized that it's even worse than I'd thought: the OAuth 2.0, Draft 30 specification even admits plainly that it is 'likely to produce a wide range of non-interoperable implementations.'<p>If that is considered an acceptable candidate for the goal of OAuth 2.0, then I would question the goal itself.<p>[1] <a href="http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/" rel="nofollow">http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell...</a><p>[2] <a href="http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-1.8" rel="nofollow">http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-1....</a>

At what point do we stop outsourcing services to the cloud and start actually building things ourselves again?<p>Hacking used to be all about solving these problems yourself. Now its about integrating a bunch of other peoples solutions. I'm gonna start a SaaS service that integrates your SaaS services. Hows that? I'll make millions.

This is super cool for getting up and running supa dupa quickly.<p>Side Q - Does anyone have conversion data on what oauth works best? If you know of a blog, video, or insight.. would love to hear about it - <a href="http://news.ycombinator.com/item?id=4675010" rel="nofollow">http://news.ycombinator.com/item?id=4675010</a>

How is this different than Janrain? <a href="http://janrain.com/" rel="nofollow">http://janrain.com/</a>

I can do the work but since users of all of the other competitors have chimed in I'll ask you to compare/contrast with OneAll.com.

Because nobody wants to give GoDaddy $70.

It would be nice with a free model which could include up to e.g. 50 users.