Home ›

Augmenting OpenID: the OpenID Token Exchange Protocol

Enable the Subscriptions block here!

Kevin Farnham
December 31, 2007

It's certainly safe to say that even now, some two years after OpenID's inception, we're still in the early adoption stages of a greater adoption curve. Big identity providers (including AOL) have helped somewhat. But, Eston Bond's push for greater relying party awareness in his AOL Developer Network article "Securing the Blogosphere Through OpenID: Relying Parties, Unite" still echoes what is perhaps the primary shortcoming of OpenID: it is much costlier to implement relying party status than it is to be the identity provider. The disparity aside, more major players are beginning to realize that OpenID is not a trend that will simply go away: David Recordon states that Blogger will be an OpenID relying party, adding another big Web 2.0 player to the list. Traversing down the long tail a bit, plugins such as WP-OpenID and Moveable Type's built-in OpenID support have helped thousands of smaller blogs become relying parties themselves.

However, OpenID's use cases have been remarkably limited thus far. Due to much of OpenID being used within the world of blogs, non-blogging or not-as-trendy sites that lie outside of the Web 2.0 realm have largely ignored OpenID. While this is in some part due to the still-early adoption phase of OpenID, it could perhaps be stated that many developers just don't get the point of OpenID. After all, we have all seen the difficulties experiences by other identity systems such as Microsoft's Passport (now Windows Live ID). In the meantime, however, aside from a few Web 2.0 stars such as Magnolia, OpenID will still find the majority of its uses as an authentication mechanism for web publishing of both blog content as well as blog comments on others' sites.

This perception needs to change. While the current OpenID use case is predominantly driven by online discussion and logging into certain web applications, OpenID's identity system still has plenty of generally unexplored use cases. While the push into the blogosphere is a great start, we cannot consider OpenID truly powerful until either it has been augmented with extra power itself or extensions to OpenID allow it to be used in more cases than is currently possible. Even if all of us were to begin using OpenID login systems for every blog and web application we own, which would be quite an awesome, successful feat, the end result would still be minimal. Even now, in these stages of early adoption, some problems with OpenID have arisen, both expected and unexpected, set in the system's architectural fundamentals.

Current limitations

While not exclusive to OpenID, the biggest problem of any authentication system is that of phishing. Even a relatively inexperienced developer can simply fake the OpenID login form, entirely falsifying the authentication process to steal passwords. In an even simpler attack, one could simply place the password field directly on the page next to the OpenID URI; given the decentralised (and currently novel) nature of OpenID, many probably wouldn't pay attention. Marco Slot, a graduate student at Vrije Universiteit Amsterdam, has written a wonderfully detailed post on this issue, outlining a fundamental problem given OpenID's decentralised nature:

Passwords no longer work in a distributed authentication system. Passwords are a shared secret between two parties, the service provider and the service consumer. With only 2 parties involved in the system your password could 'never' go the wrong way (lets not get into real network security issues). With OpenID there may be thousands of parties involved and you simply can't afford to send your shared secret in the open. Anything a user sends should be completely useless to the evil OpenID consumer without having the secret information of the provider.

Of course, those working on OpenID are far from apathetic about the issue of OpenID phishing; the OpenID wiki maintains a discussion of various ways to help curb phishing, from educating users on safe security practices to doing something much like Yahoo! does on their login pages, displaying some type of unique identifier image. The latest draft of the OpenID specification currently offers some guidance on phishing; however, the steps taken in the specification are minimal, simply advising OpenID implementers to do something to make OpenID less vulnerable to phishing, a rather vague specification that does little to actually remedy the vulnerability inherent in the system. Note: The "Token Exchange protocol", which is discussed in this article, does not address phishing issues.

OpenID identity also has flaws when APIs become involved: if you give an OpenID identity to a mashup or a site's API as your authentication method, you can only give "full delegation"; that is, the API has access to every service that you may use OpenID for, posing another security risk. For example, let's say that I have one OpenID, my single sign-on as OpenID intends to be; what if I want a web application I've written to use my OpenID identity to poll from a site like Magnolia or Basecamp? Given my identity, my application can (in the ideal state) use my OpenID identity for other things that I'm not wanting it to do. This lack of any controlled permissions on my identity causes yet another scenario where OpenID fails to work properly as part of a single sign-on system. In every situation where I may want a service to delegate certain tasks for me, I am forced to give it access to everything or nothing.

APIs also suffer from another issue, removed from permissions which may be noticeable above: I'm forced to give over my OpenID authentication credentials to a third-party, a potentially vulnerable move in itself and easily prone to the phishing attacks described above. Instead, OpenID needs a better authentication method, such that OpenID relying parties may instead invoke services on my behalf given authentication tokens from an identity provider, allowing me to sign into my identity provider directly.

Conference stirrings: Inception of OpenID Token Exchange

The problems with OpenID have resulted in new efforts to come up with solutions. For example, in his May 16, 2007 blog post "Tuesday @ IIW 2007", AOL's George Fletcher talked about a session given by Srinivas Lingutla at the Internet Identity Workshop 2007, where Srinivas discussed:

... a proposed extension to OpenID that will allow relying parties (RP) to request an authentication token from the OpenID Provider (OP) at the time of authentication. The token can then be used to access identity based web services. AOL has implemented this proposed extension and demoed it during the “speed geeking” session on Monday by using an AOL OpenID to launch a buddylist using the AOL Web IM APIs. There were a number of questions around how to support different token types (simple support already present in the proposed extension), and whether some level of application id (or provider id) is required. The next steps include evaluating the other related proposed extensions and seeing if these can be combined into a single extension to support token request and validation.

Five months later, at the Web 2.0 Summit, AOL's Edwin Aoki presented a workshop titled "Identity at the Edge". AOL's Warren Hamerman attended the session, and reported:

The discussion was lively, with a lot of participation from the audience of over fifty people. Most of the discussion centered around "security vs. ease of us", with most consumers choosing ease of use over security. It was stated that consumers expect the provider (e.g., banks and ISPs) to provide security and make it easy. It was further stated that most users choose "easy to hack" passwords and are not interested to change behavior or add additional factors (such as secure ID) to make their online experience more secure.

The panel talked about the adoption of OpenID as a means to make a user's experience easier on the web. It was also discussed that OpenID is not for every situation; in it's current form, OpenID is not recommended for sensitive information. There is a full spectrum of consumer needs to protect data. In some cases, the data is not sensitive. In other cases, the data can be very sensitive, such as personal healthcare data. Not every situation merits the same safeguards. The challenge is that most consumers don't care how the data is protected, they just want their data protected.

The session concluded with a discussion about what the next five years hold for online security. Most agreed that the conversations of today will continue, as consumers want ease of use, hackers (organized crime) continue to target consumers' data and businesses strive to protect their customers' data.

OpenID Token Exchange description

OpenID Token Exchange is certainly attracting a lot of attention, as a potential solution to at least one of OpenID's emergent problems. Let's take a more detailed look at the protocol and its proposed methods of operation.

The OpenID Token Exchange Protocol page on the AOL Developer Network summarizes the protocol's activity as follows:

A Relying Party sends a get_token message and receives an authentication token in the response. The RP can then use the token to invoke identity-based services from a service provider on behalf of the user, without requiring the user to sign in again. The service provider may require the user to provide consent for the successful completion of the service invocation from the RP.

A Relying Party "registers" with the OP using an out-of-band mechanism, prior to using the token exchange extension, and obtains an application identifier, called App ID. This application identifier is sent with every token exchange request.

What does this actually mean? The request flow diagram on the OpenID Token Exchange Protocol page (see Figure 1) makes it a lot easier to see what in fact happens:

OpenID Token Exchange request flow
Figure 1. OpenID Token Exchange request flow

In Figure 1:

  • RP is the Relying Party, specifically defined as: A Web application that wants proof that the end user controls an Identifier, and requests identity data associated with the end user
  • User Agent is the agent (typically a web browser) for the user, where "user" is defined as: A person with a digital identity who participates in OpenID-based identity information exchanges using their client software, typically a web browser or other user-agent
  • SP is the Service Provider, defined as: An application that provides identity-based services after validating authentication tokens issued by the OpenID Provider (OP)
  • OP is the OpenID Provider, specifically defined as: An OpenID Authentication server from which a Relying Party receives an assertion that the end user controls an Identifier

From this diagram, we see that the OpenID Exchange Protocol is intended to seamlessly integrate with a standard OpenID sequence. In other words, the user does not have to take any additional actions to receive the benefits provided by the Token Exchange Protocol. All of the work is automatically done by the relying party, the OpenID provider, and the service provider, all in the background from the user's point of view.

Yet, because of the acquisition of the token, the user is provided with a personalized experience, rather than a mere generic web page. The token confirms the user's identity, enabling the service provider to generate a response that is specific for that user.

Security aspects

What happens if a user's session times out, or if the user logs out? In this case the relying party can send an invalidate_token message to the OpenID provider, which then invalidates the token. Any further requests using the token (for example, if the token was somehow stolen by another user or process) will not be validated by the OpenID provider, and so the service provider will know that it should not return customized data to the relying party (and subsequently to the requesting user's browser or process).

Conclusion

OpenID has come a long way in a just a few years. AOL's adoption of OpenID and provision of OpenID to all AIM users was a significant event in extending the legitimacy and authority of OpenID as the emerging standard for creating and managing a single digital identity across the Internet.

The OpenID Token Exchange protocol extends AOL's commitment to OpenID, and provides a solution to some of the problems that have become apparent in the early phases of OpenID adoption by the web community. It's going to be exciting to watch how OpenID and the OpenID Token Exchange develop in the coming months and years.

References

» Submitted by Developer Network on January 7, 2008 - 3:39pm.