A New Identity for Web Services
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.
Pages: 1, 2 |
