What Comes Next

There is a growing trend in consumer web applications in which one site will ask users for their usernames and passwords on other sites. Using these credentials, a site will log onto the other sites to carry out actions on behalf of, and hopefully with the informed consent of, the user.

‘On behalf of’ logins

LinkedIn and Plaxo are examples of sites doing this to import contact information. In fact, Plaxo makes this functionality available as a service to developers of other applications. Slide, RockYou, Photobucket and a bunch of other widget publishers do this to smooth the process of getting their widgets on users’ pages on MySpace, Bebo, Hi5 and the others. Also, some of the more interesting mashups involve data from the deep web, and require usernames/passwords to get it from 3rd party sites.

API-based authentication

Contrast the ‘on behalf of’ approach with that of Facebook, which exposes APIs providing for access by 3rd party applications, on behalf of users, through a direct authentication by the user to Facebook. As long as the APIs support the access required, this eliminates the need for the 3rd party to collect usernames and passwords.

The fact that MySpace and others don’t have API access (or complete enough APIs) to their sites is what has driven developers to collect credentials and act on behalf of users.

Some sites actually have APIs but don’t take advantage of the fact that they could use them to tighten up security. While Salesforce could use the Facebook-style authentication for 3rd party apps, they instead have those apps solicit and store user credentials (by policy, they allow only “certified” apps to do so).

Why are ‘on behalf of’ logins a problem?

If the 3rd party site is deserving of users’ trust, and everything works properly, there should be nothing wrong with these logins. We don’t worry much about local applications doing this type of thing: blog editors, web design programs, browsers and countless other local apps all store user credentials for 3rd party apps and sites. In fact, this type of login is enabling startups to drive innovation in the new social network ecosystem; if they had to wait for the MySpaces of the world to publish APIs or enable new functionality, these companies would be dead in the water.

In reality, there are some real problems to think about. In addition to a couple of shared issues, the key differences from local applications are also the problems here:

• Trust of the application and vendor - an issue with both web and local applications. The decentralized and volatile nature of web applications, and the lack of user-centric security infrastructure (such as local anti-virus and anti-malware software), make this a tough problem for web applications.
• Authorization of the specific actions that apps take on behalf of their users - an issue with both web and local applications; if this is done really well, the problem of trust of the app and vendor is diminished.
• Location of user credentials - in web applications, these credentials live ‘in the cloud’ somewhere. The vendor claims and reality of the security of those credentials are at best hard to verify.
• Scale - the barriers of installing, and updating, local software limit the scale of this problem in that world. Web applications are easy to sign up for and can be updated multiple times a day, leading to a lot of complexity in managing overall user security.

It looks like a solution probably starts with a way to give users centralized control and management of:

• Authentication credentials
• Authorization of ‘on behalf of’ logins
• Authorization of specific ‘on behalf of’ actions

What about OpenID?

OpenID is a framework for decentralized identity. It supports decentralized authentication and structured sharing of personal information.

‘Decentralized’ in OpenID terms means decentralized from the perspective of web applications; this can in fact mean centralized from the user’s perspective. OpenID could be used to do logins on behalf of users without the collection of credentials, but it does not address the problem of authorization of those ‘on behalf of’ actions. The structured sharing of personal information involves a narrow kind of authorization, but too limited to solve this problem.

The transparency of ‘on behalf of’ action is itself a pretty complex problem - it requires giving the user a way to see and understand what the 3rd party app will go and do for them on the other site. I’m not sure whether this is a problem OpenID is interested in tackling. If it develops momentum as an identity standard, it would certainly be nice to see it go beyond authentication and identity to a more complete view of security (something Microsoft’s virtually dead Passport initiative and the Liberty Alliance project both failed to do).