I was wrestling with this too.

I implemented all of the SSOs: Live, Facebook, Yahoo (pre-oid), AOL (+ICQ/OpenAuth), plus OpenID, but then the sign in page is a disaster. I felt like it was just as hard for the user to remember which sign on service they had used the first time as to remember the username and password that they'd used. You also only get a GUID back from the SSO (for most of them), so you can't "help" other than by keeping them signed in via cookie for as long as possible.

So, then I went to just OpenID (since openid.yahoo.com), with a customized signup thing on myOpenID. But despite the best efforts of everyone, no one really cares about OpenID and "most users" don't have an OpenID, or if they do, they don't remember that they do. Of course, this depends on your target audience.

If you don't need any more information than username/password to get started then most people seem to be most comfortable with having a dumb [login(user/pass)] [register(user/pass1/pass2)]. They'll use one of the 2-3 other usernames they use in other places, and one of the 2-3 passwords they use everywhere else, and it'll suck, but they'll be logged in and you won't have lost a user to simple confusion.

So personally, I'm going with roll your own + a tiny little link to an OpenID sign in page.

Incidentally, Live is the best SSO user experience, imo (though a PITA to implement) if you felt like just picking one big one and going with it.

Personally I'm a fan of OpenID. It's open, flexible, and probably the most widely adopted single sign-on system.

I would roll my own authentication, but also support OpenID, mostly because I think "average" users would be scared away by forcing them to sign up for an OpenID first. These guys (a summer '07 YC company) might help with that problem though... http://www.clickpass.com/

I don't think the Facebook authentication API is meant to be a general purpose login system, but rather only for authenticating for use with the other Facebook APIs, much like OAuth. And I wouldn't touch Windows Live ID / Passport...

The choice of signon system depends on the type of site you have. I want my users to be able to sign up and use the service as quickly as possible.

Picking usernames can be a major source of frustration, my current thinking is the signup box should be just asking for email address and password, and roll from there. Quick and easy.

A few years ago Microsoft stopped allowing third-party sites to use Passport as a signin to their sites (except partners). Although they allow it again, I would take that as a strong warning not to rely on a third party for signin systems.

Facebook ask a lot of questions when signing up. If I didn't have a FB account, I would't be inclined to use your service if I had to tie it to a social network signin (unless your service was a facebook application).

OpenID is a massive disaster. I spent an entire day as a user reading up on it and trying to signup and use my ID on multiple sites. The whole thing is terribly complex and confusing. Every site implemented it badly. Do you want to support OpenID 1 or 2? Do your users care?

Last week I spoke to a developer on a massive site (a hugely popular new-generation audio site) and we agreed implementing an OpenID container is far from straightforward. You have to support many different things and some sites still throw errors when using OpenID Delegation (allow you to use your own domain to signin).

Unless you have a very good reason to, I'd suggest to keep far away from OpenID until they get their act together.

To recap, I want to register for a new site as quickly as possible. Just prompt for an email address and password and save yourself and your users a lot of hassle.

Well I'm glad other people are seeing the issues with this like I have. For me I think I will go with rolling my own and keeping it very simple (email/pass) and then as other systems become more usable then look to integrate into my app.

It is a tricky business though as having millions of users able to auto login to your app is very appealing(Even if it's just 1% of them)!!

If your site has sensitive data like credit card information or the like, rolling your own auth is the only good way to protect yourself and users from an incident. With openid in particular you have no idea how secure the provider is, and users will blame you if their data's exposed because they don't know better.

It depends on your market really. If you target older people, less tech-savvy people, open if, favebook and live are probably bad choices. However, a younger less tech-savvy market would do great on a facebook.live platform. Right now I think openid is still too much tech oriented for the general public.