Why I should NOT use Facebook Connect or OpenId for logging in users?

If you want a more in depth response based from someone who has dealt with this technology before, you should listen to the recent . NET Rocks with Rob Connery which was precisely about this topic dotnetrocks.com/default.aspx?showNum=626 After listening to it I decided to NOT use OpenID on my site Here is the link to Rob's blog post on the subject: blog.wekeroad.com/thoughts/open-id-is-a-....

If you want a more in depth response based from someone who has dealt with this technology before, you should listen to the recent . NET Rocks with Rob Connery which was precisely about this topic. dotnetrocks.com/default.aspx?showNum=626 After listening to it I decided to NOT use OpenID on my site.

Here is the link to Rob's blog post on the subject: blog.wekeroad.com/thoughts/open-id-is-a-....

Here are a number of reasons why not, although each comes with caveats: If you only authenticate with one external service, anyone who doesn't use that service cannot use yours. If your external authentication service goes down, users won't be able to use yours until theirs comes back up; similarly, slowdowns in their authentication server will also affect you. Requiring users to authenticate with another service requires them to accept that service's EULA, which may be a turnoff for some; similarly, it ties you morally to whatever decisions your authenticating service makes.In particular it can make you appear to be a satellite, spinoff or affiliate of the auth site, since users have to see their logo every time they try to use your service.

The external auth domain gets a perfect snapshot of your viewership, giving them a lot of insight into what your company is doing. Since their analytical tools and staff are generally top-notch, they may conceivably know more about your user base than you do. The major way to avoid this problem is to allow people to use the service of their choice, instead of a single service.

If you are limited to developing one, for development time constraints, using OpenID is the best bet because many other authentication domains also qualify as OpenIDs, and therefore ameliorates most of the above problems.

1 After looking at @santiagoIT's link, I revoke my opinion. OpenID sounds good in theory and bad in practise. In this case, it might be a better idea to stick with the 'multiple authentication hosts' idea; although as a gracenote, Mark Zuckerberg's attitude and history on privacy concerns forces me to advise against including Facebook on the list, despite (or perhaps because of) its ubiquity as an 'internet driver's license'.

– Mark McKenna Jan 24 at 16:01 Mark, I was about to go down that road when the . NET rocks episode came up. Am I glad they did that show!

– santiagoIT Jan 24 at 17:54 Indeed. Thanks for posting! – Mark McKenna Jan 24 at 20:47.

I think using IDs from any of these big names are ok as long as you don't provide service that needs an endpoint like email, IM etc. However, OpenID is just not trust-worthy. If you have any doubts, try this OpenID opennoid.appspot.com/anyid This is a disposable ID that doesn't require a password to login.

1 Likewise one could also argue that password based logins are "just not trust-worthy". A user could always chooses to share his password on bugmenot.com. If a user choose to open up his account to the world, there really isn't anything that can be done to prevent that.

I would argue that disposable IDs can be created in just about any authentication system. – Jason Jan 25 at 18:51.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.