Which authentication mechanisms should I support in a new web project?

Question

I'm about to build a new web application and I'm getting stuck on which authentication system(s) to support.

Back in the day it used to be a simple matter of creating a registration page and having everything tied to your own custom authentication provider. These days there's OpenID, Facebook Connect, Twitter and now I'm reading about OpenID Connect - a wrapper around OAuth.

So faced with the prospect of having to accommodate an ever-increasing array of authentication protocols, I'm wondering which ones (i.e. the "Open-X" variety) are the "must-haves" and which are just the "gravy".

Also, is it still considered good practice to have a Roll-Your-Own registration form or is it acceptable now to expect users to sign in using Google, Facebook or some other variation thereof?

This question is asking a similar question with the expectation of choosing one mechanism only. I'm not convinced that this is the most inclusive approach, but supporting everything surely has to be impractical.

Answer 1

I think for a developer type website SO made the best choice in picking openid. technically inclined people can pick up on openid almost instantly. IMO, if you have a general site where people that are not technically inclined are visiting they may not get it right off and may choose to go to a different site. I say, make the users choose between your own registration system and openid - this way you won't scare the non-geeks. I have a general website and have seen that people usually choose openid to login. Hope that helps

Answer 2

I'm a qualified fan of OpenId - it's good for techs, but not so for the mroe general user. So much of what you're asking can only be answered when we know your audience. If your users are also likely to be on Facebook that indicates a less technical audience so that's probably the way to go by default with OpenId as secondary mechanism. IMHO if you're on Twitter then OpenId shouldn't hold any fears and three mechanisms is at least one two many.

As for your rolling your own login page - why do you need it? It's just another page to code if you're going to let others handle the login why bother creating your own.

Answer 3

Unless you want to integrate with another site that uses a specific login mechanism, I would suggest just writing your own. It makes like simple for users and yourself. True, you will need to ensure passwords are stored securely and you should use SSL to post the login info, but this isn't that big of a deal.

If the Internet was to be re-invented today, I'm sure there would be a universal Internet login that was part of the HTTP standard and handled by DNS servers (ok, I don't know how it would work :), but unfortunately there isn't and I don't think Open ID is the answer (nor any of the other login providers).

Answer 4

This depends on what your requirements are - your reason for authenticating users, and what you can expect your users to understand and be willing to use.

In general, though, go with what's popular, because you'll benefit from more robust libraries, eyes looking at the security implications, and available service providers. Assuming you want single-sign-on, this currently seems to be either OpenID+OAuth, or OAuth WRAP. This can be subject to opinion; I recommend looking for identity-centric tech blogs and lists to see what's being discussed.

Whether to support Facebook Connect depends on your timeframe as well as your expected users. Facebook and FriendFeed are backing OAuth WRAP, so supporting Facebook Connect might not be necessary in the future.

The StackOverflow "featured" provider list isn't really relevant unless you care about what providers your users will use to authenticate. Otherwise, listing them is just a convenience for users. Frameworks such as JanRain's RPX might provide this UI for you.