https://en.wikipedia.org/wiki/Digest_access_authentication

The “response” value is calculated in three steps, as follows. Where values are combined, they
are delimited by colon symbols.

1. The MD5 hash of the combined username, authentication realm and password is
   calculated. The result is referred to as HA1.
2. The MD5 hash of the combined method and digest URI is calculated, e.g. of “GET” and
   “/dir/index.html”. The result is referred to as HA2.
3. The MD5 hash of the combined HA1 result, server nonce (nonce), request counter (nc),
   client nonce (cnonce), quality of protection code (qop) and HA2 result is calculated. The
   result is the “response” value provided by the client.
   Since the server has the same information as the client, the response can be checked by
   performing the same calculation. In the example given above the result is formed as follows,
   where MD5() represents a function used to calculate an MD5 hash, backslashes represent a
   continuation and the quotes shown are not used in the calculation.
   Completing the example given in RFC 2617 gives the following results for each step.
   HA1 = MD5( “Mufasa:[email protected]:Circle Of Life” )
   = 939e7578ed9e3c518a452acee763bce9
   HA2 = MD5( “GET:/dir/index.html” )
   = 39aff3a2bab6126f332b942af96d3366
   Response = MD5( “939e7578ed9e3c518a452acee763bce9:\
   dcd98b7102dd2f0e8b11d0f600bfb0c093:\
   00000001:0a4f113b:auth:\
   39aff3a2bab6126f332b942af96d3366″ )
   = 6629fae49393a05397450978507c4ef1
   At this point the client may make another request, reusing the server nonce value (the server
   only issues a new nonce for each “401” response) but providing a new client nonce (cnonce). For
   subsequent requests, the hexadecimal request counter (nc) must be greater than the last value
   it used – otherwise an attacker could simply “replay” an old request with the same credentials. It
   is up to the server to ensure that the counter increases for each of the nonce values that it has
   issued, rejecting any bad requests appropriately. Obviously changing the method, URI and/or
   counter value will result in a different response value.
   The server should remember nonce values that it has recently generated. It may also remember
   when each nonce value was issued, expiring them after a certain amount of time. If an expired
   value is used, the server should respond with the “401” status code and add stale=TRUE to the
   authentication header, indicating that the client should re-send with the new nonce provided,
   without prompting the user for another username and password.
   The server does not need to keep any expired nonce values – it can simply assume that any
   unrecognised values have expired. It is also possible for the server to only allow each nonce
   value to be returned once, although this forces the client to repeat every request. Note that
   expiring a server nonce immediately will not work, as the client would never get a chance to
   use it.