OpenID, Successful Failures And New Federated Identity Options
If you're a security and risk professional in charge of protecting consumer-facing applications, you may have heard that OpenID is a “toy,” or it's an insecure protocol, or other critiques. And then here comes the recent news by former early adopter 37signals to drop its OpenID login support, which has occasioned some soul-searching in the Web 2.0 identity community. Check out commentary from Scott Gilbertson of Wired's WebMonkey, Dare Obasanjo, and reaction from “social login” vendor JanRain
When OpenID appeared on the scene, more robust solutions based on SAML were well under way for many years and seeing adoption, but only in scenarios involving limited circles of trust — typically point-to-point enterprise outsourcing scenarios and specialized higher-education communities — rather than in broad-based consumer populations.
The reality was, despite a lot of talking, a lot of trying, and a lot of hoping in the formal identity standards community, consumer identity providers didn't really exist yet; OpenID opened the door to them and gave “button-based login” — which allows users to click on a button that identifies their preferred identity service for logging in at a third-party site — its start. And the “good parts” of OpenID are continuing to influence the development of new solutions and best practices for succeeding with federated login.
So I agree with Gilbertson's fairly nuanced take, which teases apart OpenID's original geeky goals from its value proposition today (for example, identifying the U.S. Federal government's support of OpenID as an important marker and noting OpenID Connect as an important way forward) and assesses it positively but not indulgently — “The legacy of OpenID may well be that it was ahead of its time, but that hardly makes it a failure.”
And really, “Whither OpenID?” isn't quite the right question to ask. Facebook — along with Twitter and LinkedIn and more — has demonstrated that, when it comes to lightweight consumer-scale federated identity, the specific protocol matters less for success than the user base, the nature of the data available about those users, and the tooling available for relying-party integration. (Do you suppose that if Facebook had chosen, say, SAML instead of OAuth for the latest incarnation of its authentication and authorization layer, third-party apps wouldn't have rushed in and hooked up to that sweet, sweet source?) And other factors and constraints come into play depending on the sort of business you're in.
The lesson, not surprisingly, is to consider the totality of your business goals and constraints in assessing the risks and benefits of becoming a relying party to the big consumer identity providers. I'll be researching this in the coming months and welcome your thoughts along the way.
As food for thought, I thought I'd share a nascent Venn diagram comparing the features of key technology approaches that may be competing for your attention in propagating and consuming identities successfully and securely beyond the enterprise.