OpenID for “single-sign-on” convenience
Posted by rokahn on 2009-March-30
OpenID is an authentication mechanism that allows users to log onto TeamPatent using their credentials at any third-party site that supports OpenID. This means that once I log onto Google Mail, I can effortlessly access my TeamPatent documents without entering my username/password for TeamPatent. We decided to support OpenID because:
- Users can’t remember many “strong” passwords so making them remember another one is burdensome.
- Users typically reuse their passwords and we don’t want any possibility compromising your accounts on other services.
- With OpenID, we can partner with other services such that users can navigate transparently from, say, Lexis or Thomson’s sites, to TeamPatent.
Clickpass harvests users’ address books
Clickpass has the most pleasant implementation of OpenID, so we gave it a trial review. After integrating with their service, we realized that when users authenticate on, say, Google or Yahoo, Clickpass requires users to give them their full contacts/address book (this is the list of names and emails for every user they’ve ever communicated with). If a user denies this request, they can’t log in with their Google or Yahoo account.
We researched Clickpass before this deployment and this intrusive requirement was not mentioned either by Clickpass or others in the blogosphere. There is no reason for a user to want Clickpass to have this information as it doesn’t help Clickpass accomplish any task on their behalf. Clickpass isn’t a social web type of site so it’s unclear how Clickpass could use this information directly. I speculate that harvesting users’ social web info and repackaging it for advertisers may be the primary reason for Clickpass’ valuation by investors.
Many sites such as Facebook, Linkedin, etc ask for permission to access your contacts list (e.g. from Outlook or your email provider). But this has always been an optional convenience (which I’ve declined). With the increasing prevalence of these sorts of social web services, users may become less concerned about divulging this information. However, we don’t feel this time has yet arrived (if it ever will) to require this openness, especially for more conservative, business users.
The other issue we had with Clickpass was that the OpenID’s it provides are in their own domain. For example, if user A comes to our site B and we direct them to Clickpass, user A would typically authenticate on a service they’re already using such as Google. However, Clickpass tells us they’re authenticated on Clickpass. This makes it very difficult for site B to ever stop using Clickpass (i.e. vendor lock-in). It would be necessary to ask each and every user to authenticate on Clickpass, supply another OpenID provider, and then turn off the Clickpass authentication. We thought at first that there was some technical reason for this indirection but it appears to be driven by other motives.
Switched to JanRain’s RPX
JanRain provides a competing service, RPX which is also free (at the basic level) and passes through to site B the ultimate OpenID provider Google. Michael Olson of JanRain explains,
No, we do not engage in vendor lock-in of any sort. So if you decide to scrap RPX and connect via OpenID directly to an identity provider, you can easily take over the system on your end without any obfuscation of data on our part.
JanRain’s RPX is free for the basic level…when users authenticate with Google, they’ll see, “Please confirm that you want to use your Google account to sign in to SiteB.JanRain.com”. If you want a “custom trust root” so users will instead see, “Please confirm that you want to use your Google account to sign in to SiteB.com”, you’ll have to upgrade. Ditto for an SLA and phone tech support. The upgrade is $0.10/user, progressively declining to $0.025/user at 1m users.
Looks like we have a contender. They also support an OpenID-type login for sites such as Facebook which aren’t OpenID-compliant. In addition, they pull user’s profile information from SREG, OAuth, and proprietary interfaces and provide it in a normalized format. We’ll see how this works out…