摘要访问认证是一种协议规定的Web服务器用来同网页浏览器进行认证信息协商的方法。它在密码发出前，先对其应用哈希函数，这相对于HTTP基本认证发送明文而言，更安全。
从技术上讲，摘要认证是使用随机数来阻止进行密码分析的MD5加密哈希函数应用。它使用HTTP协议。
摘要访问认证最初由 RFC 2069 ()中被定义。RFC 2069 大致定义了一个传统的由服务器生成随机数来维护安全性的摘要认证架构。认证响应由下列组成（HA1、HA2、A1、及A2为字符串变量的名称）：
RFC 2069 随后被 RFC 2617 ()取代。RFC 2617 引入了一系列安全增强的选项；“保护质量”(qop)、随机数计数器由客户端增加、以及客户生成的随机数。这些增强为了防止如选择明文攻击的密码分析。
如果 qop 值为“auth”或未指定，那么 HA2 为
如果 qop 值为“auth-int”，那么 HA2 为
如果 qop 值为“auth”或“auth-int”，那么如下计算 response：
如果 qop 未指定，那么如下计算 response：
上面所述的这种当 qop 未指定的情况，也就是遵循简化的 RFC 2069 标准。
在 HTTP 摘要认证中使用 MD5 加密是为了达成"不可逆的"，也就是说，当输出已知的时候，确定原始的输入应该是相当困难的。如果密码本身太过简单，也许可以通过尝试所有可能的输入来找到对应的输出（穷举攻击），甚至可以通过字典或者适当的查找表加快查找速度。
HTTP 构架由Phillip Hallam-Baker于1993年在CERN设计成的，并且没有吸收后续认证系统的改进，如基于密钥的杂凑讯息验证码HMAC的发展。虽然所使用的密码结构是基于MD5杂凑函数的，在2004年，通常认为冲突攻击不会影响明文（如密码）未被得知的应用。但是，在2006年的声明 (Kim, Biryukov2, Preneel, Hong, "On the Security of HMAC and NMAC Based on HAVAL MD4 MD5 SHA-0 and SHA-1") 导致了一些包括关于 MD5 应用的疑虑。不过，至今为止，MD5 冲突攻击没有被视为对摘要认证的威胁，并且 RFC 2617 允许服务器实现一些机制来检测冲突以及重放攻击。
HTTP摘要认证目的在于比传统摘要认证构架更安全；例如，“明显强于（如）CRAM-MD5……”。 （RFC 2617）
一些HTTP摘要认证的安全性增强如下：
摘要访问认证有意成为一个安全性的折衷。它意图代替非加密的HTTP基本认证。但是，它没有被设计为替换强认证协议，例如公钥密码学或Kerberos认证。
在安全性方面，摘要访问认证有几个缺点：
一些可以用于Web应用程序的强认证协议包括：
常用的弱明文协议：
使用HTTPS网络加密同时使用这些弱明文协议解决了许多摘要访问认证试图要防止的许多威胁。
下面的例子出自 RFC 2617，在这里进行了扩展，对每一个请求和响应显示出完整的文本。注意，这里仅仅涵盖了“auth”保护质量的代码，因为在撰写期间，所知道的只有Opera和Konqueror网页浏览器支持“auth-int”（带完整性保护的认证）。虽然定义中提到了HTTP 1.1，但是该构架可以像下面所描述的这样添加到1.0的服务器中去。
典型的认证过程包括如下步骤。
注意：客户端可能已经拥有了用户名和密码，因此不需要提示用户，比如以前存储在浏览器里的。
GET /dir/index.html HTTP/1.0Host: localhost
(跟随一个新行，形式为一个回车再跟一个换行）
HTTP/1.0 401 UnauthorizedServer: HTTPd/0.9Date: Sun, 10 Apr 2005 20:26:47 GMTWWW-Authenticate: Digest realm="testrealm@host.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41"Content-Type: text/htmlContent-Length: 311<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd（页面存档备份，存于互联网档案馆）"><HTML> <HEAD> <TITLE>Error</TITLE> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"> </HEAD> <BODY><H1>401 Unauthorized.</H1></BODY></HTML>
- 客户端请求 (用户名 "Mufasa", 密码 "Circle Of Life")
GET /dir/index.html HTTP/1.0Host: localhostAuthorization: Digest username="Mufasa", realm="testrealm@host.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"
(跟随一个新行，形式如前所述).
HTTP/1.0 200 OKServer: HTTPd/0.9Date: Sun, 10 Apr 2005 20:27:03 GMTContent-Type: text/htmlContent-Length: 7984
(随后是一个空行，然后是所请求受限制的HTML页面).
如下所述，response 值由三步计算而成。当多个数值合并的时候，使用冒号作为分割符。
因为服务器拥有与客户端同样的信息，因此服务器可以进行同样的计算，以验证客户端提交的 response 值的正确性。在上面给出的例子中，结果是如下计算的。（MD5()表示用于计算 MD5 哈希值的函数；“”表示接下一行；引号并不参与计算）
完成 RFC 2617 中所给出的示例，将在每步得出如下结果。
HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" ) = 939e7578ed9e3c518a452acee763bce9 HA2 = MD5( "GET:/dir/index.html" ) = 39aff3a2bab6126f332b942af96d3366 Response = MD5( "939e7578ed9e3c518a452acee763bce9: dcd98b7102dd2f0e8b11d0f600bfb0c093: 00000001:0a4f113b:auth: 39aff3a2bab6126f332b942af96d3366" ) = 6629fae49393a05397450978507c4ef1
此时客户端可以提交一个新的请求，重复使用服务器密码随机数(nonce)（服务器仅在每次“401”响应后发行新的nonce），但是提供新的客户端密码随机数(cnonce)。在后续的请求中，十六进制请求计数器(nc)必须比前一次使用的时候要大，否则攻击者可以简单的使用同样的认证信息重放老的请求。由服务器来确保在每个发出的密码随机数nonce时，计数器是在增加的，并拒绝掉任何错误的请求。显然，改变HTTP方法和/或计数器数值都会导致不同的 response 值。
服务器应当记住最近所生成的服务器密码随机数nonce的值。也可以在发行每一个密码随机数nonce后，记住过一段时间让它们过期。如果客户端使用了一个过期的值，服务器应该响应“401”状态号，并且在认证头中添加stale=TRUE，表明客户端应当使用新提供的服务器密码随机数nonce重发请求，而不必提示用户其它用户名和口令。
服务器不需要保存任何过期的密码随机数，它可以简单的认为所有不认识的数值都是过期的。服务器也可以只允许每一个服务器密码随机数nonce使用一次，当然，这样就会迫使客户端在发送每个请求的时候重复认证过程。需要注意的是，在生成后立刻过期服务器密码随机数nonce是不行的，因为客户端将没有任何机会来使用这个nonce。
SIP基本上使用了同样的摘要认证算法。它由 RFC 3261 定义。
大多数浏览器都基本上实现了该协议，除了某些特性，比如检查auth-int、或者MD5-sess算法。如果服务器要求处理这类可选特性，客户端可能无法进行认证（虽然需要注意的是，Apache服务器的mod_auth_digest模块也没有完全实现 RFC 2617）。
