Ask HN: Should I support OAuth or OpenID? | Hacker News Reader

Ask HN: Should I support OAuth or OpenID?

9 pointsw-ll9 comments

Working on a web app, we want to expand pass all this login/password mumbo-jumbo. We have facebook integration and are wondering if we should look at Oauth, Openid, both, or neither?

View on HN

I would look into OpenID and Twitter integration (http://apiwiki.twitter.com/Sign-in-with-Twitter). But instead of providing just a text field when accepting OpenID, provide quick links to login with the major, more-general web app providers (Yahoo, Google). You don't even need to tell your users that you're using OpenID for authentication... just that they could login using their existing account with another major web service.

You may want to look into RPX (http://rpxnow.com) - it's a commercial provider that does something similar to what I described above. I'm not a huge fan of them being a hosted service, but they do make it really straight-forward to login.

As the page you link to says, Twitter uses OAuth.

Facebook Apps use OpenID.

They do different things (federated login vs. access authorization) so focus on which you need most. Note that they are being combined, so hopefully the choice won't be necessary for too long:

http://step2.googlecode.com/svn/spec/openid_oauth_extension/...

Hmm, OAuth and OpenID are two different beasts.

OAuth is for giving your application the ability to access someone elses, without users of your application having to supply their credentials to you.

OpenID allows for users of your application to use their credentials for another service authenticate with yours.

Yeah, as the other posters have said, they're different things.

OpenID allows users to log into _YOUR_ site with a single login that they can use for other sites that support it. An alternative is your regular user/pass login (which you'll have to implement anyway for users without openid).

OAuth allows you to get data from your users accounts on other websites (twitter, yahoo, gmail etc) in a secure, supported way. An insecure and brittle alternative would be to ask your user to give you their login details for a different site on your site and then screen scrape their account.

I would say that it depends on the audience. I have to agree with xpaulbettsx, for some users it might be a problem to get the concept. However, I like OpenID idea a lot and plan to use it in my project.I just hate having 73 different user accounts on 57 different sites (I forget passwords and not all sites have nice tools to reset it).

Start with Facebook Connect if you haven't already. In terms of UX its the best single sign-on experience.

If you run a site geared towards novice computer users, my advice is DON'T. OpenID is still far too janky of a user experience, you're totally beholden to the providers, which are all different, and the "IE6" crowd just does not get it.

Both. Between OAuth and OpenID you are bound to catch most of your users (as they would be having either a Twitter account or a Google account).

Reply on news.ycombinator.com