A New Identity for Web Services

June 13, 2007

Jason Levitt

It's practically de rigueur these days for web sites with a lot of users and data to have web services. For example, YouTube.com has a set of REST web services that returns essentially the public-facing video data that users have made available on the site. A harder problem, though, is how to get at the private data of those web site users using web services. On YouTube.com, users can mark their videos as private so that the videos are never publicly displayed and won't surface via YouTube's web services. Yet, there might be a reason that users would want a third-party developer to access their private videos via a web service. The third-party developer might offer a video backup service, backing up the videos onto DVDs and then mailing the DVDs to the user. Another possibility is that the user has a personal blog and would rather that his private videos only surface on his blog.

To solve this problem, some of the larger sites on the Web (AOL, Google, Microsoft, and Yahoo, to name a few) have developed authentication APIs so that developers can access some users' private data. These authentication schemes let users grant third-party applications access to some of their private data. The applications can then make web service calls to retrieve the data. (These types of authenticated web service calls are sometimes called "identity-based web services.") It's a particularly attractive proposition for third-party web site developers, as these authentication APIs can often be used to register new users at their site in addition to providing access to private user data. Sites like buxfer.com and menuism.com have already made good use of the authentication APIs' single sign-on capability to quickly register users.

Client Authentication

There are two basic styles of authentication in use: client authentication and web-based authentication. (There is no standard naming convention for these two styles of authentication as far as I know, so that's what I call them.)

With client authentication, the third-party application asks the user for her login credentials and then uses those credentials to obtain a token, which can then be used to make authenticated web service requests. An example of a modern client authentication API is Google's ClientLogin Interface, typically used for desktop applications and mobile phone apps. With client authentication (see Figure 1), the client application prompts the user for her username and password and then sends an authentication request to obtain permission to make web service calls. The permission comes in the form of a token that the application includes in web service calls.

The main drawback of client authentication is that the user must give her username and password to a third-party application. If the application is malicious or somehow hijacked, the username and password could then be used to access all of the user's data at the site. For sites such as Yahoo! and Google, where a single login can access multiple data streams (mail, calendars, photos, etc.), this could be a particularly disastrous circumstance.

Web-Based Authentication

A more innovative method is web-based authentication, in which the user is directed to a login page at the web service providers' web site. Upon successful authentication, the user is redirected back to the third-party application, and the application is provided with a token in order to make authenticated web service requests. The key difference between web-based authentication and client authentication is that the user only enters his login credentials at the web service providers' site. The third-party application only receives a set of validation credentials, which might include the user's login ID, but never his password.

Figure 2 shows a typical web-based authentication flow using Yahoo's Browser-Based authentication (BBAuth). The third-party application first presents the user with a link that, when clicked, redirects her to a familiar Yahoo! login page. The user logs in as she normally would at Yahoo!. She is then presented with a special page where the situation is explained and she can grant the application the right to access her private data (or not). Yahoo! then sends a token back to the web application, which the web application can use to make authenticated web service calls.

Security Pieces of the Puzzle

Though AOL, Google, Microsoft, and Yahoo! have all implemented their own versions of web-based authentication, the implementations are generally quite similar. In all cases, the authentication APIs give developers access to some private user data via web services -- with the users' permission, of course.

The first step for developers, with all of these providers, is a sign-up process that provides some base-level developer accountability. Developers who want to use web-based authentication need to sign up for a shared secret or have an X.509 certificate for their application domains. Tied to these credentials are typically a few pieces of information: the domain name of the web application that will be making web service requests; a "success" URL that will be used by the web services provider to transfer programmatic control back to the third-party application after user authentication; and the "scope" of the request. The "scope" is a special buzzword that corresponds to the service the developer wants access to, such as Google Calendar or Yahoo Mail. Usually, tokens can only be used to access a single service, so you couldn't access both Yahoo Mail and Yahoo Photos using the same token; you'd need to have a separate token for each service.

Table 1 is a general overview of the web authentication features offered by AOL, Google, Microsoft, and Yahoo. Single Sign-On (SSO) means they return some identifier that can be used to uniquely identify the user. Google does not yet return such an identifier, though it clearly will offer some type of SSO option soon -- it already offers a SAML-based option for logging into Google Apps. Third-Party Site Validation explains how these sites can verify the identity of the third-party application when the user first clicks through to log in. Both Microsoft and Google require that the domain have an SSL certificate (though Microsoft also offers two other forms of validation, Mutual SSL Authentication and Relying Party Suite). Yahoo! uses a shared secret, a string that only the developer and Yahoo! know about, to digitally sign the login link, while AOL relies on the Developer ID it requires and the Success URL. AOL also provides a stronger level of authentication with its DirectLogin API (requires permission from AOL to use). Web Service Call Authentication is the technique the provider requires in order to make authenticated web service requests. The Maximum Auth Life is the maximum length of time that the third-party application is allowed to make authenticated web service calls before having to re-authenticate the user. For developers who want to test their applications quickly, both Microsoft and Google offer "untrusted" test modes, which don't require SSL certificates.

Table 1. Some security details of selected web authentication API providers

Though the Maximum Auth Life numbers may seem like a long time for an application to have access to your private data, a key feature of these APIs is the ability of the end user to revoke the privileges of the third-party application. All of the providers let users deny specific third-party application access any time after the user has granted permission by simply logging into his account and checking a box in his user profile.

Conclusion

The way users sign up at web sites hasn't changed much since the dawn of the Web. Though many proposals for identity services have been floated over the years, few have gained much momentum. These relatively simple web authentication APIs have the advantage of familiarity and the fact that neither users nor developers have to do much to adopt them. On the other hand, they are tightly bound to their respective providers, which makes them more like competing services than the universal standard that most would prefer. Of the alternatives, OpenID seems to have the mindshare and implementations, although users would have to get used to the idea of logging in with their URI instead of a username/password. Many users would need to apply for new OpenID credentials. AOL, for one, already offers OpenID as an option, although it seems likely that Google, Microsoft, and Yahoo! will eventually offer the option as well. Meanwhile, the catalog of authenticated web services that these providers offer should continue to grow providing more options for mashups and high-end web applications.