And what if the user doesn't have an OpenID yet (or doesn't realize Yahoo!, Google, etc. have implemented it)?
–
DonAug 9 '10 at 21:56

That's a very valid point. This is exactly the question, there are obviously trade-offs but what is better at the end of the day.
–
SrulyAug 9 '10 at 22:03

2

Interestingly enough, I had NO CLUE I was using OpenID to sign into this site - I used Google to make an account. I saw several buttons; one option was to sign in with Google. I liked that idea and used it. Only now, reading this, do I even see that it was OpenID. I really like that, from a user's perspective - I don't need to know anything about the backend, all I know is that it was really easy and painless to sign up, and also very easy to sign in.
–
John DApr 15 '12 at 20:03

5 Answers
5

I think currently users are more comfortable with just signing up on site, however that's mainly because that's what most websites do.

If done right OpenID and OAuth can work very well. The way StackExchange does it is particularly good. Explain what it is, show that if you have any of a certain type of account can you just press the button, and also what to do when that button is pressed. It almost makes signing up for new StackExchange sites fun (almost).

Another option is to use Facebook Connect which add a "login with Facebook" button to your site. When clicked the user doesn't leave you page but instead is presented with a Facebook style modal dialog to login, and then allow you app to get to your user date. You can even ask for special things like access to some of the users date or permission to post on the users' wall if you wish. The obvious downside with this is not everyone has a Facebook account (although over half a billion people do).

Agreed. "Login with Google", "Login with Facebook", etc. makes a lot more sense to users than "login with OpenID".
–
Robert FraserAug 10 '10 at 7:35

Would you recommend offering more than one option? say Twitter, Facbook, Live, Google, etc... or is that more confusing than helpful?
–
SrulyAug 10 '10 at 7:54

Having a few common options is a good idea. Maybe hide the less common ones by default under an other link if it looks like you have too many. It might also be a good thing to also offer on site registration if you find users getting confused or just not having any of the required web logins. I know my parents won't have either Google, Facebook or Twitter.
–
matto1990Aug 10 '10 at 13:37

2

Janrain Engage is a very well designed tool for this. You simply stick their code on your web-page and your server-side code gets all the information you'll need in JSON, the same for all the providers it supports (FaceBook, Google, OpenID, etc.).
–
Mircea ChireaAug 20 '10 at 7:36

I wouldn't trust a third-party login which didn't actually bring me to that third party. A Facebook login integrated into your page? Hell no. How do I know you aren't just stealing my Facebook details?
–
TRiGMar 12 '12 at 14:07

FWIW, I once left a site because it asked me what my OpenID was, and I didn't know how to find it. When I first used StackOverflow, it took me a second to realize why there was a URL field there instead of a username/password field. So if you use OpenID/OAuth/LiveID/etc. don't say that to users -- it's an implementation detail.

I have to say that using OpenID confused the heck out of me the first time around. I seemed to remember creating one at some point but do I put a username or an email or a url in this text box? So like Robert said, it's an implementation detail. Do we really need to ask for their open id? Ask for their username and mention on the page that you support OpenID, Google, Facebook, etc. Personally, I think it would be a lot less confusing if I didn't have to use an OpenID url on one page and an OpenID username on another.
–
LoganGoesPlacesAug 17 '10 at 0:45

My answer pretty much agrees with what's here. I'd say put twitter and facebook connect as signin options at a minimum. I'd ALMOST go with saying remove the Username/Password option altogether (not worrying about password resets and all the mumbo jumbo that goes with it are some great perks) but there is always the "slight" chance that you'll lose potential users who aren't familiar with it.

Me personally, I get annoyed whenever a site forces me to create another username/password combo and it's gotten to the point where I actually debate if using that site is worth the hassle. I expect this to become closer to the norm over time.

Whether you use single sign on (SSO) or a local method, you're still requiring the user to create an account and they probably don't want to. Try to put as much of your site's functionality in the anonymous/public realm as possible, and limit the amount of interactions that require an account (ex., you don't need an account to learn on StackExchange sites). Suck them in with goodies before you spring a defined relationship on them.

Some situations where I think SSO has a clear benefit:

You're integrating with another site or application. This could be Google, Twitter, or a company's LDAP install (think intranets and other company wide applications).

You're providing it as an alternative to a local account. I know that I almost didn't create a StackOverflow account because of SSO, but I already wanted to be a part of the site badly enough that I was willing to invest. It would have been easier if I could have created a local account, and left SSO to those who like it.

And as you've already seen, the reactions to SSO are generally positive on this site. I don't think this is surprising when you consider the people who use this site:

They already bought into SSO on some level when they used it to create an account on this site.

They most likely have an above average proficiency at using web technologies. After all, they're posting answers on a beta Q&A site about UI.

The brand "OpenID" is prohibitively tech-y, and if presented with just those two options (OpenID or local) users will probably choose "local."

However, look at Gawker, HuffingtonPost and other seriously enormous site needing authenticated participation. All of them support Facebook, Twitter, etc. logins, and most users use those options instead of local login.

The OpenID/OAuth process (single central login, distributed authentication) is preferred by users, as long as you don't actually tell them that's what's happening.