RFC 2069              Digest Access Authentication          January 1997


2.2 Digest Operation

   Upon receiving the Authorization header, the server may check its
   validity by looking up its known password which corresponds to the
   submitted username.  Then, the server must perform the same MD5
   operation performed by the client, and compare the result to the
   given response-digest.

   Note that the HTTP server does not actually need to know the user's
   clear text password.  As long as H(A1) is available to the server,
   the validity of an Authorization header may be verified.

   A client may remember the username, password and nonce values, so
   that future requests within the specified  may include the
   Authorization header preemptively.  The server may choose to accept
   the old Authorization header information, even though the nonce value
   included might not be fresh. Alternatively, the server could return a
   401 response with a new nonce value, causing the client to retry the
   request.  By specifying stale=TRUE with this response, the server
   hints to the client that the request should be retried with the new
   nonce, without reprompting the user for a new username and password.

   The opaque data is useful for transporting state information around.
   For example, a server could be responsible for authenticating content
   which actually sits on another server.  The first 401 response would
   include a domain field which includes the URI on the second server,
   and the opaque field for specifying state information.  The client
   will retry the request, at which time the server may respond with a
   301/302 redirection, pointing to the URI on the second server.  The
   client will follow the redirection, and pass the same Authorization
   header, including the  data which the second server may
   require.

   As with the basic scheme, proxies must be completely transparent in
   the Digest access authentication scheme. That is, they must forward
   the WWW-Authenticate, Authentication-info and Authorization headers
   untouched. If a proxy wants to authenticate a client before a request
   is forwarded to the server, it can be done using the Proxy-
   Authenticate and Proxy-Authorization headers described in section 2.5
   below.

2.3 Security Protocol Negotiation

   It is useful for a server to be able to know which security schemes a
   client is capable of handling.

   If this proposal is accepted as a required part of the HTTP/1.1
   specification, then a server may assume Digest support when a client




 
RFC 2069              Digest Access Authentication          January 1997


   identifies itself as HTTP/1.1 compliant.

   It is possible that a server may want to require Digest as its
   authentication method, even if the server does not know that the
   client supports it.  A client is encouraged to fail gracefully if the
   server specifies any authentication scheme it cannot handle.

2.4 Example

   The following example assumes that an access-protected document is
   being requested from the server.  The URI of the document is
   "http://www.nowhere.org/dir/index.html".  Both client and server know
   that the username for this document is "Mufasa", and the password is
   "CircleOfLife".

   The first time the client requests the document, no Authorization
   header is sent, so the server responds with:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest    realm="testrealm@host.com",
                            nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                            opaque="5ccc069c403ebaf9f0171e9517f40e41"

  The client may prompt the user for the username and password, after
  which it will respond with a new request, including the following
  Authorization header:

Authorization: Digest       username="Mufasa",
                            realm="testrealm@host.com",
                            nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                            uri="/dir/index.html",
                            response="e966c932a9242554e42c8ee200cec7f6",
                            opaque="5ccc069c403ebaf9f0171e9517f40e41"