‘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).

At TurnTide, we created a product that approached the spam problem in a new way, designed to cooperate with traditional message-by-message spam filters. The Anti-Spam Router used TCP traffic shaping to effectively reach back across the network to the spammers, and limit the rate at which traffic could leave their systems destined for a protected network. The result for customers was great; they had dramatically less spam entering their networks, meaning they saved on infrastructure costs from bandwidth to servers in addition to keeping spam out of the inbox.

The problem we faced was an interesting one… how do we count and report on the traffic that the product keeps out of the network altogether? Traditional spam filters don’t have this problem; they can count and report on all of the messages they receive, process, and mark as spam. We used a few different techniques to report on traffic that was no longer hitting our customers’ networks. We built baseline statistics when the product was initially installed, but before traffic shaping was enabled. We modeled the growth in baseline spam number experienced by the Internet at large. We added a custom reporting engine so that any statistic available to the system could be tracked, measured, compared, graphed and exported.

At the end of the day, these and other features were an effort to make a new kind product report as if it worked like the existing products in the market, since that was how customers had already learned to think about the problem. Since TurnTide really did work very differently from those existing products, reporting using the old metrics was never a perfect fit.

Building innovative products that go after existing markets from a new direction is a good strategy, and its the only way I’d ever want to enter a market as crowded as anti-spam was when we founded TurnTide. Existing markets, however, have established a way of thinking about problems and solutions. The existing vendors have educated the market, defining metrics for success in their own terms based on the structure of their solutions. Products that don’t operate within the expectations set by earlier offerings have some extra work to do; either directly re-educating the market, or trying to fit into the existing metrics until market traction allows for organic change in how people think about the problem. Even with its shortcomings, I’d definitely pick the later approach again.