

Show HN: One OAuth API for Facebook, Twitter, Google, and Email - heynk
https://www.dailycred.com/introducing-social?redirect=false

======
feralmoan
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!

I 'get it', it's awesome. Thanks for building :)

------
wallacrw
Looks awesome. I think you should reverse your header and sub-header, though.

"Simple user accounts and analytics for your website" is a much clearer
description than "Social Authentication Done Right."

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

~~~
fourstar
What's misleading about it? It's an https site...

~~~
pearkes
It's mimicking a browser UI designed to help people feel "safe" and know
they're using a website with SSL. It's probably not with malicious intent in
this case, but I'd say that's not good practice.

~~~
nostromo
We just couldn't find a better lock favicon to use. I can see your point
though, so I'll change it.

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

------
seankean
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 :)

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

------
codenerdz
This is pretty amazing. Im dealing with this very issue on my app with devise
and omniauth.

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

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?

~~~
nostromo
In this case, unless they have explicitly connected their Twitter account and
their Facebook account to your service while logged in, they will not be
logged into their account.

It's a hard problem to solve. Some companies are asking Twitter OAuth users to
provide their email upon connecting to try and get around it.

------
tantalor
How does this compare/contrast with <http://singly.com>?

~~~
dtsingletary
Singly's big offer isn't just the federation of identity and identity
services/authentication (that's just a value add and a sourcepoint). It's
treating content as collections of their social objects (status, photo, video,
location), and being able to retrieve and manipulate them irrespective of
which network they came from.

------
michaelbuckbee
This looks interesting, but I had a few questions:

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"?

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.

3\. What happens if you guys win the lottery and all retire to a tropical
island? How screwed am I with my users?

~~~
cookingrobot
Great questions - DailyCred does the account linking, so if someone signs up
with email, and then later Facebook, the accounts are linked. You can also
explicitly connect users to multiple to services, for ex if you want to have
them add their Twitter account after they're logged in.

We do both normalizing the common data, and returning the raw info/access
tokens for the social provider. So if you just need the user's name you can
grab that from us, but if you want some data that's unique to FB you can still
access all of that. We look after maintaining these social tokens for you.

Yay - we win the lottery! Or another scenario, you decide to roll your own
later.. We store passwords using standard (non-proprietary) bcrypt hashes so
you can implement your own auth system if you like. And social permissions are
granted to your Facebook/Twitter/Google apps, so you own that connection to
your user too. We're basically a proxy in the middle that handles the glue
between all the providers.

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

------
desbest
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?

Whatever API storage service is coming out next?

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

~~~
cookingrobot
Right. It turns out a lot of the work comes from gluing the various services
together. For ex, when a user signs up with an email account, and then forgets
and signs in with Facebook next time.

This takes care of deduping accounts, and flattening the social data, etc.

(FYI, I'm with DailyCred)

~~~
spullara
Looks really cool. We took a swipe at this at Bagcheck as well through search:
[https://bagcheck.com/blog/02-design-solutions-for-new-log-
in...](https://bagcheck.com/blog/02-design-solutions-for-new-log-in-problems)

------
fmavituna
Very good idea however:

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.

Not to mention this:

"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)."

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.

~~~
nostromo
You'll never get a mixed content warning on our site if you don't play the
YouTube video.

Unfortunately, even if you use YouTube's https embed, it still redirects the
browser through a single http site. It's annoying and I don't like it, but
neither YouTube or Vimeo offer pure https best I can tell just yet.

As for implementing HSTS (as we have on our site) - it's great advice. We
understand that a man in the middle attack could rewrite a customer's non HTTP
page and send them to a site that looks like Dailycred but is not. (Facebook
by and large suffers from the same vulnerability.) But compared to not
implementing HTTPS at all, we think Dailycred is a huge step up.

------
biscarch
Is there a use case supporting native (iOS, Android) apps?

To me, the site seems to be targeted at web platforms (Which I'm considering
using for a current project).

------
chimeracoder
This looks incredibly useful! However, its existence raises an important
question.

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 _cannot_ exist.

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.

 _EDIT_ : 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.'

If that is considered an acceptable candidate for the goal of OAuth 2.0, then
I would question the goal itself.

[1] [http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-
hell...](http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/)

[2] [http://tools.ietf.org/html/draft-ietf-
oauth-v2-30#section-1....](http://tools.ietf.org/html/draft-ietf-
oauth-v2-30#section-1.8)

~~~
nostromo
Cofounder here. You're absolutely right. OAuth 1 (still used by Twitter) is a
huge pain to implement. OAuth 2 (Google, FB) is easier, but the
implementations are different enough to cause a lot of headaches.

So, we agree that OAuth is flawed. Where there is a problem, there is an
opportunity. :)

By the way, add in Email/Password, and new things like Persona (which we'd
like to add soon), and auth has gone in a few short years from being
incredibly basic to quite complicated. We hope to abstract away all of that
noise and just give devs a single API for identity.

------
slajax
At what point do we stop outsourcing services to the cloud and start actually
building things ourselves again?

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.

~~~
jonny_eh
Hackers use the best tools available to them. It just so happens that a lot of
tools are now hosted in the cloud instead of running on your desktop.

There's pros and cons to this approach. If you don't like it, don't use it.
You're free to roll your own or use a gem like devise.

------
allbombs
This is super cool for getting up and running supa dupa quickly.

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 -
<http://news.ycombinator.com/item?id=4675010>

------
zrail
How is this different than Janrain? <http://janrain.com/>

~~~
nostromo
Cofounder here. Good question. A few key areas:

You implement OAuth 2 on your side, so you're not tied to a proprietary API
forever. (You can think of it as an OAuth proxy.) If you already have
implemented Facebook OAuth, you can plug us in and add Email, Twitter, etc.,
with almost no additional work.

Our Username / Email / Password flow (and APIs) are more dev and user friendly
than Janrain's -- which has been more focused on social.

If you use Ruby, you can use our Gems to get set up very quickly.

We're also cheaper since our feature set is closer to Janrain's Enterprise;
you can get started today without talking to a sales guy.

Our homepage also has 100% less lightning animations. ;)

Happy to answer more questions here or via email: juliuss@dailycred.com

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

------
desbest
Because nobody wants to give GoDaddy $70.

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

~~~
nostromo
Sign up, and when it asks for your credit card, click "I'll do this later."

You'll be entered into our unadvertised free tier that goes up to, you guessed
it, 50 users.

