Authentication-Info auth response

What it does

Authentication-Info is sent by the server in a successful response (after authentication has been validated) to provide the client with additional information about the completed authentication exchange. Its primary use is mutual authentication — giving the client proof that the server also knows the shared secret, confirming the server is legitimate.

In practice, Authentication-Info is almost exclusively associated with Digest authentication (RFC 7616), where it carries the server's response digest (rspauth) that the client can verify. It's rarely encountered in modern systems, which have largely moved to Bearer tokens and session cookies.

Syntax

Authentication-Info: <param>=<value>[, <param>=<value>]*

Example (Digest auth):

Authentication-Info: nextnonce="newNonce456", qop=auth, rspauth="6629fae49393a05397450978507c4ef1", cnonce="0a4f113b", nc=00000001

Parameters

Mutual authentication with rspauth

The key value proposition of Authentication-Info in Digest auth is rspauth — a hash the server computes using the shared password. The client verifies this hash to confirm:

1. The server received the correct request
2. The server knows the correct password
3. The response hasn't been tampered with in transit

This two-way verification is what makes Digest auth "mutual" — both sides prove they know the secret. Basic auth provides no such guarantee; a server could be impersonated without the client knowing.

Modern relevance

Authentication-Info is primarily a Digest auth header, and Digest auth itself is largely deprecated in modern web development. The reasons:

• Bearer tokens (JWT/OAuth) dominate API authentication
• Session cookies handle browser authentication
• TLS provides the transport security that Digest auth tried to achieve at the HTTP layer
• Digest auth is complex to implement correctly and prone to subtle security mistakes

You'll encounter Authentication-Info if you're:

• Maintaining legacy enterprise applications that use Digest auth
• Working with certain SIP (VoIP) systems, which borrowed HTTP Digest auth
• Integrating with older WebDAV servers

Proxy-Authentication-Info

Proxy-Authentication-Info is the exact proxy equivalent — sent by a proxy after successful proxy authentication, echoing and confirming the Digest exchange at the proxy level. Same parameters, same purpose, different context.

Real-world example

Digest auth exchange with Authentication-Info:

GET /protected HTTP/1.1
Authorization: Digest username="user", realm="example.com",
  nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
  uri="/protected", qop=auth, nc=00000001,
  cnonce="0a4f113b",
  response="6629fae49393a05397450978507c4ef1"

HTTP/1.1 200 OK
Authentication-Info: qop=auth,
  rspauth="2206f89b3e71c41e9d4b7c42bbbf7b94",
  cnonce="0a4f113b",
  nc=00000001,
  nextnonce="e66aa6d92b8f26b4e6a4e1c8ab34d6a3"

The client verifies rspauth to confirm the server's identity. nextnonce is used on the client's next request.

FAQ

Do I need to implement Authentication-Info for Bearer auth?

No. Authentication-Info is specific to challenge-response schemes like Digest. Bearer token authentication has no equivalent — the token itself is the proof of authentication. For JWT/Bearer APIs, you'll never see or need to set Authentication-Info.

Is Authentication-Info required for Digest auth?

Technically no — Authentication-Info is optional in the Digest auth spec. Servers can successfully complete Digest auth without sending it. But without rspauth, the client has no way to verify it's talking to a legitimate server rather than an attacker who intercepted the request.

Where is Authentication-Info used outside HTTP?

SIP (Session Initiation Protocol), used for VoIP, borrowed HTTP's authentication mechanisms including Digest auth and Authentication-Info. If you work with VoIP infrastructure, you'll encounter this header in SIP messages.

Fun fact

Digest authentication — the primary use case for Authentication-Info — was designed in 1997 (RFC 2069) as a more secure alternative to Basic auth that avoided sending passwords in clear text. For a few years it looked like the future of HTTP authentication. Then TLS became universal, making transport-layer encryption the standard solution, and Digest auth's complexity with no corresponding security advantage over "Basic auth over HTTPS" relegated it to legacy status. Authentication-Info is thus a survivor from an authentication scheme that was obsolete almost before it was widely deployed.