OAuth: Emergence of Network Centric Identity

For 5 or more years now, there has been a push by many in the identity management industry to rally around the idea of user-centric identity. Why not give users complete control over information being shared between web sites? From a web service provider it should make sense. Why retain data if it could be provided easily by the user? It made a lot of sense. Thus user-centric identity was born. There was a lot of interest, but user-centricity has remained esoteric and hasn't really taken off...

At the recent IIW 11 meeting, Dick Hardt led a discussion on the decline of user-centric identity. The conclusion was predictable. Lack of big players with significant financial incentives, too many negative financial incentives, and finally launching with immature technology not able to meet security, functionality or usability requirements. But I'm not so sure that fully explains the issue.

Both InfoCards and OpenID had some great new thinking. They both evolved around the idea of either a single user-agent or a single identity provider. User-control was key to both offerings putting the user at the centre. Neither approach was accepted by the market except in limited ways. I think that a big part of the problem was a design that focuses on a single point of control or distribution - a centricity. Both of these approaches ended up creating functional "silos" that limit the ability to embrace the Internet. Though with good intent, I think they fell into the same trap that applications fall into when they manage their own security and identity management. The application works, but it is a limited use silo with potential elevated risk and management costs. Further as application silos get big, the pressure to bridge the silos has increased. As evidence of this look at social networking application today and the Google/Facebook API sharing debate.

A new option has emerged that may serve to rejuvenate user-centric protocols by adding a new capability - open authorization or OAuth. OAuth enables applications and service providers to access data with the permission of users. Instead of trying to solve data transfer and user authentication at the same time, the requirements are separated. Yes, data can still be transferred as part of authentication, but now, many more use cases are handled without needing the users to be present. Instead of just applying to typical data points about users (first name, last name, etc), OAuth enables access to services that are controlled by users. Much more powerful. OAuth in combination with OpenID, SAML, or InfoCards enables new network cases like photo printing services, game boxes, cell-phone applications.

OAuth brings forward the notion that too me is a multi-agent or network-centric approach that enables controlled sharing of personal information by parties with some level of independence. For example, a user can give a game-box a one-time token that enables it to access his online game profile automatically. No longer does the user need to perform complex authentication in a device that doesn't have a keyboard. Instead, the user enables the device to act as an "agent" on his or her behalf. In fact there are many use-cases now envisioned (see the Zeltsan use cases draft).

OAuth enables applications to have independent relationships with data providers by using tokens as proof they are working on a user's behalf. With OAuth, applications access each other's services while allowing access control systems to handle authentication and authorization and more importantly, as I outlined in my last blog post, it allows the authorization system to distinguish between an OAuth client and a user. The OAuth concept is important because it enables network-centric identity.

I am glossing over a lot of issues (like the security of tokens, which I'll address in later posts), but the essential point, is that OAuth enables users to authorize applications, devices, or web services to perform actions on their behalf. This can be done with the user present (browser based), and with the user absent from ongoing exchanges of information. This is done with tokens (bearer, holder-of-key, etc). The OAuth 2.0 draft describe several scenarios in which users can enable a "client" application to obtain an access token to access user-controlled information on their behalf. Example, a service like Mint.com can aggregate financial information from investment services or banking service; a photo printing service can obtain photos from flickr for 24 hours to allow it to print a set of photos. A Twitter client on an smart phone can have a long-lived token to allow a user to easily post and read updates from services like twitter.

In short, network-centricity allows users to form a web of relationships between service clients and service providers. In this approach, emphasis on private 'silos' are minimized and authorized shared access to authoritative information is emphasized. Because applications have easy access to authorized, quality data, the need to copy and retain information is reduced as network services are embraced and adoption is more likely.