About OpenID
OpenID provides a mechanism by which a user may be authenticated by using a third party. This means the site consuming the Open ID does not have to maintain tables with user ID and password hashes (although providing parallel support is advisable). When a user chooses to login, they are redirected to the third party site, Google for instance, in order to authenticate themselves and come back to the originating site on a call back URL. Similar to the way card payment providers send the browser to the bank to enter the verified by Visa or Mastercard secure code authentication. The call back will contain a valid authentication token if the authentication was a success. The newer versions of Open ID also allow details of the user stored by the third party to be retrieved from their profile. Details such as email address may be requested or required to be sent. This information may then be used to pre-fill registration forms or wipe out the need for registration forms in extreme examples.
Most internet users already have an Open ID, even though most don’t know it. This is courtesy of large internet players such as Google and Yahoo. Account holders on these services and many others automatically create an Open ID for users. The appeal of OpenID to the website owner is that the user will find it easy to authenticate themselves with a registration process that is minimised or eliminated. The attraction to the user is that they finally do not have to manage hundreds of passwords for all the sites they visit because everyone uses a unique password every time -right?
Implementing OpenID
I considered OpenID a while back but dismissed it as too geeky for a mainstream eCommerce site to use. The integration was painful at the time and the user experience was poor. Now times have moved on and there are libraries that can be included in a project that provide for easy integration of OpenID such as DotNet OpenAuth. There are also javascript projects that address some of the clunky user interface issues experienced in the early days. They present the OpenID login as familiar service icons, see Openid Selector Project. There are variants that give graphical drop down boxes for the available services too.
Using OpenID for B2B
I am in no doubt that for consumer sites such as Kmartin the US and for personal sites like blogs. they can benefit from allowing users to login using OpenID. The question is should we use OpenID today for a business to business website? It is appealing that people can click on familiar Facebook or Google icons to login to the site but the fear is that by doing so, all too often the captured identity of the person would be domestic, not their professional work identity.
As time goes on the way identities are managed by individuals may converge but at the moment there is too much risk of fragmenting database marketing activity data with these personal profiles. It is not unreasonable to think that a customer logging into a site with Facebook will end up, through ignorance, providing their home account details. Domestic email addresses are an inappropriate channel to communicate with them through for order confirmations, marketing initiatives, etc.
Is there no work around?
Perhaps when a new OpenID is authenticated and comes back into the site we could ask if the email address of the OpenID is the same email address they want to correspond with us on and allow the user to add a correspondence address. The only problem is that we have not authenticated against that address if they do this that sort of feels like a bad idea. Certainly this does not help us with say rules that automatically map domain names of email addresses to account numbers as we can not allow this person to place an order on an account for which we cannot guarantee they are authorised to do so. It would be interesting if readers have found ways to work around this issue.
Security concerns
A college raised the concern of what if the OpenID password is compromised by a key logger or similar? Would this make a site using OpenID open to fraud? It does, although in reality most people use the same passwords across most sites, thus the risk is not greatly increased, but it is certainly present. It is a concern and a better understanding of the risks before committing to any OpenID scheme would be required. There is a lack of awareness as to how important protecting these big portal logins is amongst the internet population. Many are not aware the amplitude of damage that may be caused by compromising, say a Google identity. Think of how many site could be accessed in that user’s name.
Another related question regards customers with many branch offices or larger teams of people. It is possible to for a suitably privileged user in that organisation to create and manage user accounts for their staff on our site for those other workers. OpenID would not change this as the association between an account created with an email address can be picked up when a user logs in as the OpenID provider will return an email address for the user logging in. This is assuming we have got the same email address as the OpenID provider, bit assumption given what we are saying about domestic logins earlier.
Conclusion
It is disappointing that we will not be implementing OpenID as it would clearly provide benefits to users that understand how to manage their identities in that framework. Unfortunately for B2B websites I don’t think the paradigm is well enough understood by the end users and hence confusion may ensue leading to long telephone support calls with customers.
It is reasonable to assume that non IT workers have not created the appropriate professional and domestic identities with the authenticating sites. One exception is Linkedin , promoted as a professional network here people are more likely to have set up accounts in the context of their employment. Unfortunately as far as I am aware Linkedin does not support OpenID yet.
References