Benefits of a RESTful Architecture | 205stored for as long as the sessions are valid (if sessions last an hour, the server must
hold all newly generated nonces for an hour). This serves to prevent replay attacks; if
this information were not kept and verified, an eavesdropper could simply “replay” a
sniffed authentication handshake and convince the server that he is the original user.*
The problem with keeping any application state on the server is that it hinders scal-
ability. For a pool of 100 application servers to implement HTT PBasic authentica-
tion, they need only share the list of valid login/password combinations. But for the
same pool to implement Digest authentication, the servers should share a list of
issued nonce values to defend against replay attacks.
HTT Pauthentication is desirable from a RESTful perspective, because it minimizes
or eliminates session state kept on the server. There are other options for authentica-
tion; perhaps the most common in Rails is to use the session mechanism to store the
ID of the currently logged-in user. Typically, this session is indexed by a key that is
given to the client. Newer versions of Rails store a server-signed copy of the entire
session in a cookie. This is actually more RESTful, but it is vulnerable to some of the
same replay attacks as Digest authentication (other Rails session storage is not vul-
nerable, as a direct consequence of its server-side state). It is of course up to the
application developer to draw the boundaries, depending on the application’s secu-
rity needs and the consequences of session replay.
There is another solution that can make HTT Pauthentication practical. For applica-
tions that can handle a JavaScript dependency, Paul James has created an ingenious way
to use HTT Pauthentication with HTML forms. Details are athttp://www.peej.co.uk/
articles/http-auth-with-html-forms.html. This method uses XMLHttpRequest to try
an authentication through HTT Pagainst a remote server. Once the authentication is
complete, the credentials are stored as usual in the browser and used on future
requests to the protected content. There are a few rough edges with browser support
(the logout feature is not supported in Internet Explorer), but otherwise this is a
wonderful solution.
Benefits of a RESTful Architecture
In this chapter, we have touched on some of the benefits that a RESTful application
architecture can provide, and hopefully you have seen some of those benefits for
yourself. Now we will list and explain each of the major benefits that REST strives to
achieve.
- Although RFC 2617 does not mandate any checking of nonce values, it suggests it, subject to the applica-
tion’s need for security against replay attacks.