The main difference is that it doesn’t require sending the username and password across the wire in plaintext. It is also immune to replay-attacks, as it uses a one-time number from the server.
The server gives the client a one-time use number (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 then access is granted, otherwise it can send back a 401 Unauthorized (no login or failed login) or a 403 Forbidden (access denied).
Digest authentication is standardized in RFC2617. There’s a nice overview of it on Wikipedia:
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.