A New Identity for Web Services
by Jason Levitt | Pages: 1, 2

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

	Single Sign-On	Third-Party Site Validation	Web Service Call Authentication	Maximum Auth Life	Test mode?
AOL OpenAuth	userid returned	Developer ID and Success URL	Token in request	One year	No
Google AuthSub	no	SSL with SSL certificate	SSL Certificate - signed requests	No expiration	Yes
Microsoft Windows Live Contacts API	userid returned	SSL with SSL Certificate*	Token sent over SSL	No expiration	Yes
Yahoo BBAuth	hash of userid returned	SSL with shared secret	Cookie in HTTP header	14 days	No

*Microsoft also offers two other forms of validation, Mutual SSL Authentication and Relying Party Suite.

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.

---