Authentication
Many web services and web applications need authentication of their users. Unfortunately,
RESTful authentication on the human-readable Web is in a sad state.
RESTful HTTPweb services designed to be consumed by machines tend to have
more options, because the developer of the application can somewhat dictate how
the client must connect, even if it involves custom authentication schemes.
For browser-based web sites and web applications, there are fewer options; for an
application to be usable by humans on the public Web today, it needs to support the
browsers its clients will be using.
There are two methods commonly supported in browsers for HTTPauthentication:
Basic and Digest. Both are defined and explored in RFC 2617 (http://tools.ietf.org/
html/rfc2617). Basic authentication is very simple, but it is insecure. Usernames and
passwords are sent in plain text over the network.* Digest authentication is a step up;
it uses a challenge/response mechanism for the client to prove it knows the password
without sending it over the network.
Digest authentication could technically violate the statelessness principles of REST.
The nonce values that the server generates during the authentication process must be
* The easiest solution, as with forms-based authentication, is to encrypt the entire login transaction with SSL.
Benefits of a RESTful Architecture | 205
stored for as long as the sessions are valid (if sessions last an hour, the server must
hold all newly generated nonces for an hour).
Pages:
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320