# Authentication-Info Header

> Learn how Authentication-Info provides additional authentication data in responses to successful requests. Covers digest authentication and session info.

Source: https://howhttpworks.com/headers/authentication-info
Last reviewed: 2026-10-05

> **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](https://www.rfc-editor.org/rfc/rfc9110#section-11.6.3) defines the general field; [RFC 7616 §3.5](https://www.rfc-editor.org/rfc/rfc7616#section-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
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

```text
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:

```javascript
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](https://www.rfc-editor.org/rfc/rfc7616#section-3.4).

### 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:

```apache
<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](https://httpd.apache.org/docs/2.4/programs/htdigest.html):

```bash
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](https://httpd.apache.org/docs/2.4/mod/mod_auth_digest.html) is an MD5 Digest implementation, not the SHA-256 diagnostic above. Its [response hook](https://github.com/apache/httpd/blob/2.4.x/modules/aaa/mod_auth_digest.c) 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:

```bash
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:

```javascript
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](https://www.rfc-editor.org/rfc/rfc7616#section-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:

```javascript
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](https://www.rfc-editor.org/rfc/rfc7616#section-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:

```bash
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](https://howhttpworks.com/headers/authorization)
- [WWW-Authenticate](https://howhttpworks.com/headers/www-authenticate)
- [Proxy-Authenticate](https://howhttpworks.com/headers/proxy-authenticate)
- [Proxy-Authorization](https://howhttpworks.com/headers/proxy-authorization)