< Authentication-Info: nextnonce="dcd98b7102dd2f0e"

TL;DR: Authentication-Info carries scheme-specific response parameters, without an authentication scheme prefix. For Digest, it can supply nextnonce and a computed rspauth. Nonces are not necessarily single-use, and omitting nextnonce does not force a new challenge.

The field supplements an authentication exchange. RFC 9110 §11.6.3 defines the general field; RFC 7616 §3.5 defines Digest’s parameters. Its semantics depend on the authentication scheme used in the corresponding request.

How Authentication-Info Works

After validating a Digest-authenticated request, a server may advertise a different nonce for the next request. This illustrative empty response supplies only that optional parameter:

HTTP/1.1 200 OK
Authentication-Info: nextnonce="server-generated-next-nonce"
Content-Length: 0

The client should use a received nextnonce for its next authenticated request. A server may tolerate the older nonce for a limited time to allow concurrent or pipelined requests.

Syntax

Authentication-Info: parameter=value, another-parameter="quoted value"

Unlike Authorization or WWW-Authenticate, the value does not begin with Digest. For Digest, nextnonce, rspauth, and cnonce use quoted strings; qop and nc do not.

Common Examples

nextnonce rotates the server challenge. rspauth allows a client to verify response authentication. When using qop=auth or auth-int in Authentication-Info, include rspauth, cnonce, and nc; the last two must match the request.

Digest parameter	What to check
nextnonce	Quoted server nonce for a future request; optional.
qop	Unquoted auth or auth-int; should match the request.
rspauth	Quoted response digest using the selected algorithm.
cnonce	Quoted value copied from the corresponding client request.
nc	Eight unquoted hexadecimal digits copied from that request.

A response with qop=auth but no rspauth, cnonce, or nc is incomplete. Rotating a nonce alone is a different operation from proving knowledge of the authentication secret.

Server Implementation

For SHA-256 with qop=auth, this executable diagnostic calculates rspauth from explicitly chosen inputs. It is not an authentication middleware or a nonce-validation implementation:

import { createHash } from 'node:crypto'

const H = (text) => createHash('sha256').update(text, 'utf8').digest('hex')
const username = 'alice'
const realm = 'example'
const password = 'example-password'
const nonce = 'example-server-nonce'
const cnonce = 'example-client-nonce'
const nc = '00000001'
const uri = '/protected'

const ha1 = H(`${username}:${realm}:${password}`)
const ha2 = H(`:${uri}`) // response A2 has no HTTP method
const rspauth = H(`${ha1}:${nonce}:${nc}:${cnonce}:auth:${ha2}`)
console.log(`Authentication-Info: qop=auth, rspauth="${rspauth}", cnonce="${cnonce}", nc=${nc}`)

Save as .mjs and run with Node. Request authentication uses METHOD:uri for A2; response authentication uses :uri. auth-int adds a response-body hash. Session algorithms also change A1; do not reuse this calculation for them. See RFC 7616 §§3.4–3.5.

Apache Digest endpoint

For an existing Apache deployment that uses Digest, configure a protected directory and inspect the module’s actual response. This assumes DocumentRoot /var/www, so /protected/ maps to /var/www/protected. Adjust the directory and AuthDigestDomain for your deployment. It requires mod_auth_digest, its file authentication provider, and a readable content directory:

<Directory "/var/www/protected">
    AuthType Digest
    AuthName "api"
    AuthDigestDomain /protected/
    AuthDigestProvider file
    AuthUserFile /etc/apache2/users.digest
    Require valid-user
</Directory>

Create the credentials file with Apache’s htdigest utility:

htdigest -c /etc/apache2/users.digest api alice

The realm api must match AuthName. -c creates or truncates the file; omit it when adding a user to an existing file. Protect the credential file from web access and make it readable by the server.

Apache’s mod_auth_digest is an MD5 Digest implementation, not the SHA-256 diagnostic above. Its response hook constructs Authentication-Info, including response authentication for applicable exchanges. Inspect what your installed module emits rather than inserting a static field with Header set. That static value cannot match different nonces and request URIs.

Getting Authentication-Info right

Match the algorithm, nonce, client nonce, nonce count, URI, and qop from the actual exchange. Returning only nextnonce supplies no response-authentication proof. Use a Digest implementation that verifies requests and tracks nonce policy before sending a success response.

WWW-Authenticate supplies a challenge and is required on a 401 response. Authentication-Info supplies response parameters for the scheme already used. It is not a generic login-session extension header.

Testing Authentication-Info

For an endpoint that actually supports Digest, let curl perform the challenge exchange and prompt for the password:

curl --digest --user alice -D - https://api.example.com/protected -o /dev/null

Replace the URL and username with your test endpoint and account. Inspect the success response separately from the initial 401 challenge. Absence of Authentication-Info is not itself proof of authentication failure.

For an already authenticated same-origin endpoint, browser code can inspect the response field without manually forging Digest credentials:

const response = await fetch('/protected/', { credentials: 'same-origin' })
console.log(response.status, response.headers.get('Authentication-Info'))
await response.arrayBuffer()

A null result can mean the field was not sent. On a cross-origin request, it can also mean the server did not expose it through CORS. Authentication-Info is not a CORS-safelisted response header; add Access-Control-Expose-Headers: Authentication-Info only under the intended CORS policy. This is separate from proving the response digest.

nextnonce and Replay Attack Prevention

A Digest nonce can be reused under server policy. For requests using qop, the client increments nc for that nonce, and the server can detect repeated counts. One-time nonces are an option, not a universal rule. Replay protection requires server-side validation and tracking; merely adding nextnonce does not provide it. RFC 7616 §5.5 discusses replay attacks.

A client using qop formats nonce counts as eight hexadecimal digits. This counter illustrates that formatting for a single nonce:

let count = 0
function nextNonceCount() {
  if (count === 0xffffffff) throw new Error('Nonce count exhausted')
  return (++count).toString(16).padStart(8, '0')
}
console.log(nextNonceCount()) // 00000001

Reset the count when adopting a new nonce. A concurrent client needs coordinated allocation so two requests do not use the same count; server-side replay tracking also needs atomic updates. The formatting helper does not perform either task. If you receive stale=true in a new Digest challenge, follow that challenge rather than reusing cached response parameters. RFC 7616 §3.3 defines stale handling.

Digest response authentication does not encrypt traffic. Keep TLS protection and authentication logic separate from header formatting. Compute response authentication from the actual exchange parameters.

When checking nonce rotation, make two transfers in one curl process and inspect both header sets:

curl --digest --user alice -i http://127.0.0.1/protected/ \
  http://127.0.0.1/protected/

A client may reuse authentication state between transfers. Compare the new challenge, Authorization parameters, and Authentication-Info together; the presence of nextnonce alone does not show that the client adopted it.

Related Headers

• Authorization
• WWW-Authenticate
• Proxy-Authenticate
• Proxy-Authorization