The only difference, as far as I know, is that it doesn't requires sending the username and password across the wire in plaintext.
The server gives the client a one-time use string (a nonce) that it combines with the username, realm, password and the URI request. The client runs all of those fields through an MD5 hashing method to produce a hash key.
It sends this hash key to the server along with the username and the realm to attempt to authenticate.
Server-side the same method is used to generate a hashkey, only instead of using the password typed in to the browser the server looks up the expected password for the user from its user DB. It looks up the stored password for this username, runs in through the same algorithm and compares it to what the client sent. If they match: access is granted, otherwise it can send back an 401 request to have the user retry or an access denied error (I forget the code sorry).
There's a nice overview of it on Wikipedia: http://en.wikipedia.org/wiki/Digest_access_authentication
Edit: I don't know if I made that any clearer that the wikipedia article, sorry!
You can think of it like this:
- Client makes request
- Client gets back a nonce from the server and a 401 authentication request
- Client sends back the following response array (username, realm, generate_md5_key(nonce, username, realm, URI, password_given_by_user_to_browser)) (yea, that's very simplified)
- The server takes username and realm (plus it knows the URI the client is requesting) and it looks up the password for that username. Then it goes and does its own version of generate_md5_key(nonce, username, realm, URI, password_I_have_for_this_user_in_my_db)
- It compares the output of generate_md5() that it got with the one the client sent, if they match the client sent the correct password. If they don't match the password sent was wrong.