Case study on the perils of identity federation

This forceful critique (to put it mildly) of OpenID from a website/business owner perspective highlights one of the main leaps of faiths involved in federation: taking a dependency on a third party for the well-being of your own business.

There is a lot going on in the debacle described in the original post. Some of them could be attributed to “implementation issues,” the vague catch-all category that is the equivalent of “pilot error” we fall back on to explain away incidents without attributing a systematic cause: JanRain randomly changing APIs without proper communication, Google changing the  identifier returned, inconsistency between user profiles returned by different OpenID providers etc. These are not supposed to happen– better change tracking could have prevented some of the bone-headed mistakes involved. Instability of the OpenID standard and general lack of interoperability among implementations is an unfortunate outcome of the highly politicized standards process that results from reluctant bringing together avowed enemies to the negotiating table. (Inexplicably the US government has decided to throw its weight behind this already hobbled standard, by empowering the Nationals Institute of Health to work on a pilot program for federal adoption.) But again this is business as usual in trying to forge consensus for Internet standards, and not intrinsic to the problem of OpenID in particular or interoperability in general.

At the same time there are deeper issues at play, and these are inimical to any identity federation scheme . To quote the metaphor used by the original author:

[…] of all the failure points in your business – you really don’t want the door to be locked while you stand behind the counter waiting for business. No, let me rephrase that: you don’t want the door jammed shut, completely unopenable while your customers wait outside – irate that you won’t let them in.

Put simply, when users login to your website using a third-party identity provider (“IDP”) your business is at the mercy of that provider. If they experience a service outage, users can not login to your website either. If they decide to experiment with brand new user interface that confuses half the users, your website loses traffic.

Some of the risks can be mitigated contractually. For example the IDP could commit to a particular service level agreement, saying they have an expected uptime of 99.99%. But no IDP in existence is willing to shoulder the burden of full liability for losses incurred at relying party sites. Your website can make a compelling case that the inability to authenticate new users for an hour has resulted in loss of a thousand dollars, going by historic traffic patterns. The most you are likely to get out of the IDP are profuse, heartfelt apologies and at best a refund for that month. The incentives are highly asymmetric.

One could argue that specialization and economies of scale will compensate for this: JanRain is presumably handling authentication for thousands of web sites. So they are in a position to invest in very high-reliability infrastructure and maintain strong security posture. In principle then they are less likely to experience an outage (compared to what each relying party is capable of) less likely to get breached in an embarrassing manner as Gawker recently managed to, and more likely to respond to security incidents quickly in the worst case scenario. On the other hand, as probabilities for catastrophic failure decrease, the damage potential from that failure is going way up. An outage or breach at JanRain impacts not just the author of that blog post, but every other business using the OpenID interop service. More importantly, this is not a linear function of number of users: scale attracts scrutiny, both from white hat researchers and black-hats looking to capitalize on a lucrative target.

The above scenario only considered unintentional outages. What about cases where service is withheld on purpose? Presumably the IDP is getting paid by the site for their service. What happens when it is time to renew the contract? What if negotiations with the IDP go south and they decide to hold your users “hostage,” by refusing to authenticate them to any RP except yours until you agree to the higher price? If users are only known by their external identity, it is going to be very difficult to reestablish the link. The article quoted above describes the escape hatch required: collecting email address from users, so they can be authenticated independently, presumably by verifying their email. Of course that obviates one of the arguments for OpenID, namely individual websites no longer have to worry about the complexity and cost of operating their own authentication system. It turns out this is what the original post concluded, changing the site to nudge new users to their in-house authentication system instead of promoting OpenID.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s