Show HN: One OAuth API for Facebook, Twitter, Google, and Email | Hacker News Reader

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

dailycred.com

93 pointsheynk41 comments

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

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

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

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

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.

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

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.

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?

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.

How does this compare/contrast with http://singly.com?

Check out the pricing of both offerings. I'd imagine there are a lot of indies who would choose DC.

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.

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?

Great questions. I couldn't stop thinking about #3 while watching that video.

Edit -- Seems like he answered #1 in another commment: 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.

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.

1. Yes, if a user forgets how they logged in and use a different provider, we either log them in or prompt them to use the first provider, depending on if their account email has been verified.

2. We do normalize common fields. It's done server-side however so you won't see it in the gem.

3. Not screwed. :) You can export your passwords (we use bcrypt) and keep all your social accounts as well. Because at the end of the day we're just another OAuth provider, you're not tied to us as a provider.

Edit: my cofounder also responded. Go team! 😃

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?

Whatever API storage service is coming out next?

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

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)

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

In that case, amazing. I've been looking for something like this. Will have to give it a try.

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.

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.

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

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

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

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.

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.

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.

Do you really want to solve every single problem yourself? Do you think you are the best person for every problem? Outsourcing can be a good idea because it leverages other people's strengths to build a better overall product....

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

How is this different than Janrain? http://janrain.com/

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

If you're looking for a free alternative, check out SSI from AddThis:

http://www.addthis.com/labs/social-sign-in#.UIBqXRj0CnM

You will have to store your user info yourself, but it does take care of oAuth for you. Full disclosure: I work for AddThis and worked on this feature.

About $50k a year.

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.

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

Reply on news.ycombinator.com