I am using Digest Authentication to check if a user knows the ID and PW of the server. Once the client has entered the server because it knows the credentials (the server has matched its hash response with the client's hash response), all of its requests have the Authorization header. This is normal? Authorization header is not sent only once?
Once the client has passed the Digest Challenge, all of its requests look like the following (all requests have the Authorization header):
GET /XMLAliasRegDev HTTP/1.1
***Here's the Host***
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Accept: */*
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://***Here's the Host***/webpage/html/registry.htm
Authorization: Digest username="xxx", realm="xxx", nonce="b463d286b77fba6535adc1902e43377a", uri="/XMLAliasRegDev", response="4bedc10d3fd7f3fb90ab518ffead238b", opaque="eb2cdfdb6ebd0e78c0737bc4d58d0d3c"
Connection: keep-alive
GET /webpage/scripts/regjs.js HTTP/1.1
***Here's the Host***
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Accept: */*
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://***Here's the Host***/webpage/html/registry.htm
Authorization: Digest username="xxx", realm="xxx", nonce="b463d286b77fba6535adc1902e43377a", uri="/webpage/scripts/regjs.js", response="95cd7035c6abf7666fbdb0068aa69b9a", opaque="eb2cdfdb6ebd0e78c0737bc4d58d0d3c"
Connection: keep-alive
If the server has matched the responses, the responses matched, and the server sends the resources to the client because the client entered the correct credentials, why does the client send the authorization header on each request? Is this the way Digest Authentication works?
Thank you very much!
PS: I am using Arduino as a server.
This is how it works, because HTTP is a stateless protocol, once authorized, credentials must be sent in each request. Simplifying the rfc example quite a bit , the round trip is more or less like this:
On the first request from the client, the server says 401 (hey! I need identification) and gives it a token made up of a nonce (one-time use value), an opaque (session state indicator) and an authentication realm (scope). https://www.rfc-editor.org/rfc/rfc2617#section-3.2.1
Client request (no authentication)
Server response
the client asks the user for a key, takes the realm and the nonce/opaque and generates an auth token (response) that it sends together with the original request (it includes an order number nc and a client nonce cnonce). https://www.rfc-editor.org/rfc/rfc2617#section-3.2.2
Client request (username "Mufasa", password "Circle Of Life")
the server receives the token (nonce/response/opaque), nonce from the client (cnonce), and calculates based on this whether the client can access the resource. https://www.rfc-editor.org/rfc/rfc2617#section-3.3
Server response
if the client receives an ok (200 OK) it will continue calculating based on the nonce/realm of the first 401 and sending the calculated cnonce and response to avoid another 401.
the server at any time can invalidate those credentials and present another 401 (authorization needed) with another nonce/opaque, indicate a 400 (bad request) and so on.
The English explanation of the example: https://en.wikipedia.org/wiki/Digest_access_authentication#Example_with_explanation