For a few months now I am considering implementing OpenID for JungleDragon. But some things are holding me back. Hereby I want to share those things. 

First, a very limited explanation of what OpenID is...

OpenID is designed to avoid the issue of having a set of credentials for each seperate website that you sign up for. Unlike previous commercial attempts like Microsoft Passport, OpenID is a non-profit organization that seems independent and free of any special interests.

How does it work? OpenID is a distributed authentication model. OpenID is not a singular service that lets people authenticate to all websites from a single place. Instead it defines a standard for authentication and let others implement it. Those are called providers. Sites like Yahoo and Facebook are providers of OpenID authentication. 

Sites that let users log in via OpenID are called OpenID consumers. Some sites are both providers and consumers. In theory, OpenID brings two very practical benefits:

• For users, it will be easier to join and sign into web applications. They can reuse their set of credentials at a trusted service of their choosing.
• For developer, there no longer is a need to waste effort on implementing login forms, login logic, account management such as password resets, and the general need to store user passwords securely. All of this is "outsourced" to the provider. All a developer needs to do is link the open ID to his own internal user store.

Such is the theory, but as often in life, real life gets in the way...

OpenID usability

You'd think that OpenID improves usability, and it can. But there's a few drawbacks too. 

The first problem is in OpenID adaptance. Very few OpenID consumers exist (sites who accept an OpenID login). Therefore it not considered a convention. Your users may not be used to signing in the OpenID way or may not trust giving their credentials to a site this way. But there is more confusion. It seems a proprietary authentication mechanism called Facebook Connect is gaining popularity too. This is yet another way of signing in. Unlike OpenID, Facebook Connect's authentication stays on the original site, which is better for usability.

Second, the OpenID experience is different. With OpenID, you basically sign in using a URL (of your provider), and next optionally using your provider's authentication mechanism (most often email address and password, but not if you're signed in to the provider already). In this process, the user is taken from the original site to a different site and then back. 

A popular way to make signing in using OpenID easier is to place shortcuts of the most likely or popular providers at the login screen, as is implemented by StackOverflow:

I am a big fan of this implementation. But I'm an internet savvy user with an existing account at one of these providers. Not all users will be in this situation or will be comfortable with this method. And what if their provider is not listed? They can log in using the field at the bottom but how usable is that? How we can we expect a "common" user to even know what OpenID is, how it works and remember their provider ID?

OpenID security

OpenID is as secure as the OpenID provider is. Google Mail is my provider and I trust that it is safe.

That does not mean that OpenID in a holistic scenario is safe though. The biggest threat is phishing. Users who regularly use OpenID will be comfortable with a site redirecting or popping up a login form of the provider of the user. This trust can be misused easily. I can create a login screen and place popular provider icons on it. Next, when the user clicks on Google, I launch a popup with a fake copy of the Google login form. The address bar will still be in green. My fake popup will not have the Google.com URL but only eagle eyed users will notice this or even know that this would matter. Next, I capture the user's credentials and their Gmail account is "hacked".

As far as I know there is no solution for this. It is inheritent of the fact that you authenticate at another site.

OpenID effort

OpenID can save a developer a lot of work in authentication, password storage, etc. However, it can also add a lot of work and complexities. Whilst I have not done an OpenID implementation yet, I did read into it and investigate the issues. The most common challenges seem to be:

• If you truly would like to server a large group of users, you will want to implement OpenID on top of your own authentication logic. This is to maximize the comfort of the entire user group. This issue may not apply for a controlled environment or special audience. Needless to say, if this issue occurs, OpenID will only add effort, not reduce it.
• Actually implementing OpenID robustly seems to not be trivial. One big issue is that there are differences in how the different providers actually handle and implement OpenID. You may need to make a few code variations of the same thing.
• At one point, you will need to integrate OpenID identifiers with your own user store. Such an implementation can be confusing, because you need to offer the user a way to disassociate a provider with your internal account. Why? Perhaps because the user no longer holds an account at his provider or perhaps because the provider just stopped their service. To make matters worse, the same user could authenticate to your site using different providers.

My impression so far is that implementing OpenID is not impossible or rocket science, but not trivial either.

Conclusion

I've passively went through the thougts above for a few months now. I can see the value in OpenID, but I don't take the drawbacks lightly. For now, I've decided to not implement OpenID in the first version of JungleDragon, a decision I may revisit at any point. My main reason for not going the OpenID way right now is in the messy authentication landscape (OpenID, Facebook Connect, Twitter oAuth, etc). The other reason is effort. With a long todo list and limited resources, it just does not play it at this point.

This post was mostly me publishing my internal decision making. I hope it is useful in triggering you to think about OpenID as well. What do you think is it's future? The consequences of an implementation? Reasons to use it or not?

RATE THIS CONTENT (OPTIONAL)

	Was this document useful to you?
	Rating:	Awesome  Good  Average  Poor  Useless

CREATE A NEW COMMENT

	Name:
	Email:
	Website:
	Content:	HTML is not allowed. Hyperlinks will automatically be converted.