HTTP Digest Authentication

Why Digest Authentication Was Created

After HTTP Basic cam out, developers quickly realized it was unsafe:

• Passwords were sent Base64-encoded, not encrypted.
• Anyone sniffing network traffic could decode user:password.

So the HTTP working group designed a new mechanism in RFC 2069 and later RFC 2617 called HTTP Digest Authentication.

Its goal:

“Let clients prove they know the password – without ever sending the password itself.”

The Core Idea – Hash the Password Before Sending

Instead of sending username:password directly, Digest Auth uses:

• A cryptographic hash (MD5) of your credentials
• A server-supplied random challenge (called a nonce)

So even if someone captures the traffic, the only see the hash –  not the actual password. And that hash changes every time because the nonce is random.

How HTTP Digest Authentication Works

Let's break the flow down:

Step 1: Client makes a normal request

GET /protected HTTP/1.1
Host: example.com

No credentials yet

Step 2: Server challenges the client

HTTP/1.1 401 Unauthorized
WWW-Authentication: Digest realm="User Area",
nonce="a1b2c3d4e5f6",
qop="auth",
algorithm=MD5

Here's what those mean:

• realm: Name of the protected area
• nonce: Random string to make each request unique
• qop: “quality of protection” (usually auth)
• algorithm: Hashing algorithm (MD5 by default)

Step 3: Client calculates a hash response

Client computes these values internally:

1. HA1 = MD5(username:realm:password)
   • user's fixed secret hash
2. HA2 = MD5(method:digestURI)
   • e.g., MD5("GET:/protected")
3. Final response:
   • response = MD5(HA1:nonce:HA2)

Then sends this header:

Authorization: Digest username="alice",
realm="User Area",
nonce="a1b2c3d4e5f6"
uri="/protected",
response="6629fae49393a05397450978507c4ef1",
qop=auth,
nc=00000001,
cnonce="0a4f113b"

Step 4: Server verifies

Server does the same hash calculation using the stored password.

If the response hash matches -> success.

If not -> 401 unauthorized

Why It's Safer Than Basic Auth

Digest authentication stopped attackers from trivially reading credentials from network packets – a big win in the 1990s.

Why It's Rarely Used Today

Despite being clever, Digest Auth faded away because of:

• Limited browser and library support
• Still based on weak MD5
• No support for tokens or modern auth
• Difficult to integrate with APIs, mobile apps, and OAuth
• HTTPS made it mostly redundant – since HTTPS encrypts everything (including Basic Auth headers)

So, once HTTPS became the norm, Digest's main advantage vanished.

Today, most APIs use Bearer Tokens / OAuth instead.