Da wird Username und Passwort nochmal extra durch eine Hash-Funktion wie MD5 geschleust (siehe Beispiel)
Laut https://en.wikipedia.org/wiki/Digest_access_authentication wird bei MD5-sess ja folgendes gemacht:
HA1 = MD5(MD5(username:realm:password):nonce:cnonce)
hast du das auch so nachgebaut?
Probier mal noch , dass du die Requests mit einem Tool wie z.B. https://hookbin.com/ vergleichst. Vielleicht kommst du ja so dem Unterschied auf die Schliche.
Wurde per Ticket geklärt. Wir haben HTTP Digest Authentication direkt in die HTTP-Accounts eingebaut. Damit sollte diese Authentifizierung auch out-of-the-box funktionieren.
Testen kann man das beispielsweise mit
[http://httpbin.org/#/Auth/get_digest_auth__qop___user___passwd_](http://httpbin.org/#/Auth/get_digest_auth__qop___user___passwd_)



Ein paar Hintergrundinfos:
Unser intern genutzter HTTP-Client macht dabei das ganze Digest Auth Handling und erkennt dabei automatisch die ganzen Dinge wie qop, nonce, algorith usw. von der Gegenseite. Dieses Digest macht bei der ersten Anfrage auch eigentlich 2 HTTP-Requests im Hintergrund. Im ersten Call wird die Gegenseite angefragt, und die verweigert erstmal mit einem 401 und einem WWW-Authenticate Reponse Header. In diesem Response-Header stehen nonce, der verwendete Algorithmus (z.B. md5 oder md5-sess) usw. drin. Das wertet unser Client aus und macht entsprechend den zweiten verschlüsselten Call. Dieser zweite Request geht dann normal durch, sofern Username und Password korrekt sind.
Hinweis: Beim SpreadsheetURL Download werden aber nicht jedes mal 2 HTTP-Requests gemacht, sondern nur beim ersten mal. D.h. ein SpreadsheetURLDownload der eigentlich 10 Requests machen will, macht bei Digest Auth 11 Requests.