The Promise and Problems of OpenID
Widgets & RSS FeedsNew Web-based services crop up at an astonishing rate. The problem is that with each new service, a new signup process with a unique username, password, and often bits of personally identifying information are required to create a new account. Not only is this process maddening in its repetitiveness, but also each account adds additional management overhead. OpenID allows users to have a single identifier that may be used to log onto every service that accepts OpenIDs for authentication.
OpenID is an authentication framework that has the potential to be a mainstream Internet-scale Single Sign On (SSO) mechanism. However, the OpenID framework also has a number of substantial security challenges that it must overcome in order to avoid creating bigger problems than it solves. In addition, OpenID must gain much greater adoption with consumers, service providers, and software developers so that the network effect is large enough to matter. Brad Fitzpatrick originally created OpenID in 2005 as an authentication mechanism for the LiveJournal service he was developing at the time. The second major revision of the OpenID protocol was released in 2007, at the Internet Identity Workshop, where much of the consensus for community development work is achieved. The authors of the OpenID specification, along with a number of active members and organizations developing OpenID, formed the OpenID Foundation in June 2007 to ensure that the intellectual property and trademarks related to the specification remained controlled by an independent entity.
OpenIDs are presented as URLs such as http://username.openidprovider.com/. Identities may be delegated using a few simple auto-discovery headers that allow users to present an OpenID such as http://username.hostingservice.com/blog/ that redirects to the OpenID Provider. Users may also maintain multiple OpenIDs. OpenID is often referred to as a user-centric identity management system meaning that the user is theoretically in control of their online identity. The system is technically decentralized meaning that there is no single authoritative component, company, or service that controls or owns the OpenID infrastructure. There also is not a single point of failure for the system as a whole. However, as I will discuss later, the amount of control and potential for points of failure are relative to the amount of control the user has over the domain that is tied to their OpenID.
Slow Adoption
Many services and platforms popular with early adopters have begun to support OpenID as either a client or server. Most of the large Web-based service providers (AOL, Google, Microsoft, and Yahoo!) have promised OpenID support. However, there are major challenges to adoption and OpenID is still virtually unheard of in the public-at-large. In particular, most OpenID-enabled services only provide an OpenID login (typically called Identity Providers or OpenID Providers) rather than a Relying Party (an OpenID client formerly known as a Consumer). This means users have many options for OpenID usernames and passwords, but relatively few services to log into. OpenID security—in particular protection from phishing attacks—still needs significant development.
There are a number of problems facing the widespread adoption of OpenID. When simply looking at the number of potential OpenID users, the outlook is rosy as increasing numbers of large service providers are also OpenID Providers. However, numbers for actively used OpenIDs are hard to come by. As noted above, part of the problem is that the majority of high-profile OpenID Providers (AOL, Microsoft, and Yahoo!) are only providers and not Relying Parties. While these services are happy to let other sites authenticate against their infrastructure with IDs that they issue, they do not allow users with OpenIDs from other providers to authenticate to their infrastructure. These are about as useful as a new credit card, with attractive rates, that few merchants will accept. In a sense OpenID competes with a host of other frameworks, protocols, systems, and standards such as SAML, the WS-* services, LDAP-based authentication, Kerberos, and RADIUS. Most of these are running in production services with large active user-bases.
While OpenID has a number of security and privacy problems that it needs to overcome, one of the most urgent is providing greater protection from phishing attempts to OpenID users. One major risk of SSO systems is that a compromised account may result in the attacker having access to multiple systems beyond the compromised individual service. In some ways, this is only incrementally worse than existing practice, as people tend to have just a few passwords and use the same passwords for similar types of services. Limited numbers of passwords combined with usernames—which increasingly are simply email addresses—lead to a situation where a compromised account could easily be used on multiple services. OpenID will become an increasingly vulnerable target unless there is improvement to OpenID’s limited protection from phishing attacks.
Growing Risks
Since OpenID is a distributed SSO system, the provider with the weakest security puts all Relying Parties at risk. For example, any provider or Relying Party that is compromised or even vulnerable to Cross Site Scripting (XSS) attacks, Cross-Site Request Forgeries (CSRF) could also be used to compromise users logins. There are significant privacy risks as OpenID Providers potentially engage in large-scale tracking by maintaining a list of every site that the user authenticates to via OpenID.
Another risk of SSO systems, even distributed ones such as OpenID, is that they can be a single point of failure. For example, when a power outage at 365 Main colocation facility forced many sites offline, including Six Apart makers of TypePad, LiveJournal (since sold), and Moveable Type, during the outage all OpenIDs associated with the LiveJournal service became unavailable. Similarly, with a recent DNS outage on my own server, all services associated with the OpenID hosted on my domain became unavailable. This is a sobering thought. While most mainstream consumer services have extremely high uptimes, recently there have been a number of high profile failures. A failure with the service hosting your OpenID would cause all of your OpenID enabled logins to fail as well. This risk will grow as OpenID adoption grows. Again, this risk is not inherent to OpenID alone, however it should be a consideration when choosing whether or not to rely on any SSO and when choosing a SSO service.
In order to improve adoption rates, many OpenID enabled sites need to improve the usability of logging in with OpenID for end-users. First, most users are comfortable with service specific usernames even if they do find creating new credentials for each service cumbersome. Increasingly, services make use of an existing email address for the user identifier in order to avoid the problem of users finding a unique username for each service. OpenID logins often require the user to click through to a secondary login page on the service, thus requiring more effort than the standard login. Although the process may be slightly simplified, many OpenID enabled services still require an account creation process to attach local data to the external OpenID. OpenID is facing an uphill battle with both consumer recognition, as well as convincing users that the OpenID framework provides enough benefit to warrant learning new behaviors.
OpenID is clearly gaining in adoption and importance. Currently, OpenID is both too lightweight for enterprise identity management and too insecure for sites with financial or other highly sensitive data. Some of the current problems will be mitigated by OpenID extensions and new more secure mechanisms for OpenID authentication and improved phishing protection. Businesses, especially those with consumer Web-based services, would do well to familiarize themselves with the technology and pay attention to its progress.
