Take the 2-minute tour ×

I have a simple question: Is it possible to use Digest-Authentication with a XMLHTTPRequest?

If the answer is no, what's the technical reason? Or if it is possible - how can I do that?

Thanks a lot … google has no good answer so far :-/


Thanks for the answers. Modifying the header to match the digest authentication-scheme, after a nonce has been received, seems to be a solution.

But what I was really looking for was that I could change my current call: xmlhttp.open("GET", url, false, username, password); to sth. like that xmlhttp.open("GET", url, false, username, password, "DIGEST");

That’s also part of my initial question: Why does the open-method not offer the option to make a digest-request?

Maybe there is js-lib one could recommend that lets me do that - as you imagine I don't really want to change the one and simple xmlhttp.open to multiple requests and first get a nonce.

share|improve this question
What have you tried so far? If your server page requires Digest auth (returning a 401 to unauthenticated requests), and you pass a username and password into your XHR open() call, everything should work just fine. –  EricLaw Aug 23 '11 at 13:08
Have you done it ? I would be really apreciate some code. Thanks! –  vrunoa May 23 '12 at 21:41

4 Answers 4

up vote 6 down vote accepted

You can do it no problem. Just follow the parts of the specs you feel like ;)
and is all you are missing to start writing your authentication library
on the client side.

pre-exchange user name and password
Hey I want to authenticate ----> server
Ok here is a nonce/salt ----> client
here is a md5 hash sum of my username password timestamp and the salt -----> server
I just hased up your password and username the same way you did and they are the same ----->client
Those are the basics of it.

I left out that you need to include the URI of the requested resource in the hashsum!!!!
Of course you do this with every request you make for a resource to the server that way some one intercepting the hash could only view the content you requested and could not make a request for a miscellaneous resource.This method does not secure the data just access to it.

share|improve this answer
I disagree. Anyone can ask for a nonce to the server. How do you want to transport that safely to the client-side? –  Chielus Aug 23 '11 at 10:59
You dont it is just to make it more difficult to figure out your password from the md5 and make each authentication attempt unique. http://en.wikipedia.org/wiki/Cryptographic_nonce. This way some one can not man in the middle you hash and re authenticate with it at another time. In fact they use a nonce in Oauth. I know what you are thinking thats still totally insecure but the purpose of this type of authentication is just to preserve your user name and password. It is very basic. –  James Andino Aug 23 '11 at 11:05
: / What was the down vote for? –  James Andino Aug 23 '11 at 13:17

The best way to do this is by using SSL. I don't think any other safe solution exists (correct me if i'm wrong)

share|improve this answer
Not wrong just cautious ; ) –  James Andino Aug 23 '11 at 11:10
Digest is more secure than Basic + SSL! Check out RFC 2617, the section on security. –  wprl May 8 '13 at 3:50
Without SSL, an MitM attacker (e.g. hostile or compromised proxy; say at a public WiFi access point) can inject arbitrary JavaScript (or simply links) to the HTML. This way the attacker's requests will originate from the users' browser, thus the server won't have any chance to tell that these are not from the user. The attacker does not even need to figure out the password. –  robert4 Sep 26 '13 at 13:13

Have a look at this article : http://marcin-michalski.pl/2012/11/01/javascript-digest-authentication-restful-webservice-spring-security-javascript-ajax/. It explains how to do JavaScript client for Digest Authentication with SpringSecurity in the server side. The code is available in github : https://github.com/Arrowgroup/JSDigestAuth

share|improve this answer
This is the best answer. Pointing to someone's post that has done all the work and it provides the full source code (with a very easy way of testing it) –  Jonathan Jul 4 '13 at 15:48

I have coded a full workflow for this, it's not difficult at all once you are using an external library for MD5 (I use Crypto-js).

The greatest issue you might have is that on the first server 401 reply any of the most used browsers will open a dialog box for getting your credentials. As far as I have seen there is not easy way to circumvent this: How can I supress the browser's authentication dialog?

To solve it, I modified the webserver which I coded from a C# codeplex project. On the first request the client passes a "Warning" header saying "Do not raise a 401". The server creates the challenge and sends it back with a custom, non-401 HttpException (I use 406 for the moment, which is "not acceptable" in HTTP). The client creates the hash and sends it back.

I can post some code snippets if anyone's interested, this is kind of an old question.

share|improve this answer
This doesn't seem to be true for Safari, when it receives 401 over an XHR. –  wprl May 8 '13 at 3:52
What do you mean by "this"? "this" = "the browser opens a dialog box also for XHR 401"? If that is the case, there is no need for the warning header trick. Widely-compatible solutions would still require a workaround. –  malber May 8 '13 at 7:44

Your Answer


