New Web App / Website - Authentication

(Not sure if this was a programming or startup question, but I will ask you guys) Authentication on a new website:

Should I go with OpenId, or use my own Forms-based authentication. My website is not geared towards technology buffs, so I am thinking I might scare people away with OpenId. Also, Forms-based is a lot easier (for me) to get up and running.

I would like to offer OpenId in future releases, but I am wondering if I am going to cause myself more headaches by not fully implementing OpenId in the beginning.

Why not offer both? I would definitely go with forms-based authentication, specially if your users are not tech savvy, OpenId is great but I have heard from many people offering SaaS solutions that not many people use it. I am currently working in a SaaS product myself and I am using forms-based authentication... if enough people ask about OpenId then I'll implement it later.

It depends on your market but I would generally say no.

You're unlikely to lose users by only implementing forms based, but you may lose them if you only implement OpenID.

If this is true for your market, you need to implement forms based. You can add OpenID at a later date, but you should only do so when you have nothing more important to add (which may well be never).

I personally dont see any reason to adobt open id. The benefits for small sites are not that great. As for user experience, i think its about the same. Its nice to be able to do a one click registration, but asking someone for an email, name and password is not that devestating where you are going to lose users.

My opinion do what is easiest.

You should implement form based authentication, but take care on what platform you'll use.

For instance, if you're using Ruby On Rails, you could use https://github.com/intridea/omniauth or https://github.com/binarylogic/authlogic - that will allow you grow your authentication mechanism as your needs evolve.

You'll find that with most modern web frameworks there are plenty solutions like that available.

If you are going to offer OpenId in future releases I would suggest that you either implement or at least work out how you are going to implement it now.

If you build a username/password type sign on and later want to add OpenId support you may find yourself rewriting large parts of the code and database, not to mention having to rework the whole flow of the sign on process.

If you at least think it through (how will you display, store and authenticate different users) and have your database ready with any extra columns you can make the decision to adopt or not at a later phase.

Just go with the forms-based authentication. If your app gets up and running AND you see a demand for OpenID you can look at implementing it.

I've never seen a web-app where OpenID made up any signficant number of users (say more than 2%). In addition, with the popularity of Facebook, Twitter, and LinkedIn sign-in you would probably be better off (after your app is running) looking at implementing those.

Stop 10 random people tomorrow and ask them if they have an OpenID (outside of a developers conference or the Google campus). I would be shocked if more than 1 of them said yes. Then ask them if they have a Facebook or LinkedIn account. You'll probably get 5-6 yes responses - more if you are asking younger people and/or office workers.