HTTP Authorization Header

-1

I am using Digest Authentication to verify 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? Is the authorization header not sent only once?

Once the client has approved the Digest Challenge, all their requests are as follows (all requests have the Authorization heading):

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 answers, they have coincided, and the server sends the resources to the client because the client has entered the correct credentials, why does the client send the authorization header in each request? Is the Digest Authentication way to work?

Thank you very much!

PS: I'm using Arduino as a server.

    
asked by Kane12 02.07.2018 в 12:16
source

1 answer

2

This is how it works, because HTTP is a stateless protocol once authorized, you must send credentials in each request. simplifying quite the example of the rfc , the round trip is more or less like this:

At the first request of the client the server says 401 (eh! I need identification) it gives a token composed of nonce (value of a single use) an opaque (indicator of session status) and a realm (scope) of authentication . link

Client request (no authentication)

GET /dir/index.html HTTP/1.0
Host: localhost

Server response

HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2014 20:26:47 GMT
WWW-Authenticate: Digest realm="[email protected]",
                        qop="auth,auth-int",
                        nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                        opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 153

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>Error</title>
  </head>
  <body>
    <h1>401 Unauthorized.</h1>
  </body>
</html>

the client asks for the password the user takes the realm and the nonce / opaque and generates an auth token (response) that he sends next to the original request (it includes an order number nc and a client nonce cnonce). link

Client request (username "Mufasa", password "Circle Of Life")

GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
                     realm="[email protected]",
                     nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                     uri="/dir/index.html",
                     qop=auth,
                     nc=00000001,
                     cnonce="0a4f113b",
                     response="6629fae49393a05397450978507c4ef1",
                     opaque="5ccc069c403ebaf9f0171e9517f40e41"

the server receives the token (nonce / response / opaque), nonce of the client (cnonce), and calculates based on this if the client can access the resource. link

Server response

HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984

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 can at any time invalidate those credentials and present another 401 (needs authorization) with another nonce / opaque, indicate a 400 (bad request) and so on.

The explanation in English of the example: link

    
answered by 02.07.2018 / 20:16
source