HTTP认证基础
基础认证(Basic)
说直白点，认证就是让访问服务的人提供用户名和密码，然后对用户名和密码做校验。
http的质询/响应认证框架
客户端和服务器的质询/响应认证过程：
- 客户端发送请求；
- 服务器收到请求后，判断如果请求的资源需要认证，则返回401状态，并在response headers中加入WWW-Authenticate头部，要求客户端带上认证信息以后再发一次请求；
- 客户端收到401返回信息后，重新向服务器发送请求，并在request headers中加入Authoriaztion头部，用来说明认证的用户名、密码、算法等信息；
- 服务器再次收到请求后，判断认证信息无误，返回200，并在response headers中加入Authorization-Info头部。
借用http权威指南中一图来说明认证过程：
安全域
服务器第一次返回中WWW-Authenticate头部中包含realm参数，作用为标识访问资源的安全域。服务器对不同数据区域可以设置不同的访问权限，安全域字段的作用相当于告诉客户端要访问的资源属于服务器众多区域中的那一片区域里。
基础认证
WWW-Authenticate头部中的Basic指的就是基础认证（另外一个Digest指的是另一种认证方式：摘要认证，详见后文）。
Basic Auth超级简单，客户端在输入用户名密码后发送请求，浏览器会用一个冒号“：”将用户名和密码连接起来，然后做一下Base64编码（关于Base64说明详见http://blog.sina.com.cn/s/blog_87bd61ee0102wwfy.html），就直接把这个编码后的字符串放到Authorization头部里发给服务器了。
代理认证
服务器可以委托代理服务器提供对内部资源的统一访问控制，即代理认证。
代理认证的步骤与服务器认证相同。但首部的状态码有所不同。
摘要认证(Digest)
摘要认证利用摘要算法（如MD5）对重要数据做不可逆编码，来防止恶意截获信息后获取敏感内容。
摘要认证的握手机制
客户端和服务器的质询/响应认证过程：
- 客户端发送请求；
- 服务器收到请求后会生成一个随机数nonce（见下文随机数选择）放在WWW-Authenticate头部，返回401状态。如果要求增强保护质量（QoP，可对实体主体做完整性校验），则将支持的QoP属性也放在WWW-Authenticate头部。
- 客户端选择一个算法（auth或者auth-int），计算出密码和其他数据的摘要，将摘要(response)和算法(qop)放在Authorization头部中。如果客户端还要对服务器进行认证，则生成客户端随机数(cnonce)、随机数生成次数(nc)也放在Authorization中发送服务器。
- 服务器收到算法及支撑数据（请求方法、请求uri、服务器随机数等），计算出摘要，与客户端摘要进行比较，验证是否匹配。另外如果客户端发送cnonce，服务器会再生成一个随机数(nextnonce)出来，然后根据nextnonce、cnonce、实体主体等等生成应答摘要(rspauth)，加到Authorization-Info头部中，返回客户端。
- 客户端收到返回后，再算出摘要，与服务器返回的rspauth比较，验证是否匹配。后如果还要发送请求，重复3、4、5步骤。
摘要算法
（1）算法基础：
- H(v1) = MD5(v1); 将v1进行MD5编码
- KD(v1, v2) = MD5(v1 : v2); 将v1和v2用冒号”:”连接后进行MD5编码
- A1表示包含安全信息的数据块，A1=(user):(realm):(password)；
- QoP（保护质量），对不包含安全信息的数据设置保护方式，可选项：auth、auth-int
- A2表示不包含安全信息的数据块，根据qop值确定：
a) QoP=auth或undefined时，A2=(request-method) : (uri-directive-value)
b) QoP=auth-int时，A2=(request-method) : (uri-directive-value) : H((entity-body))
（2）老摘要算法
兼容RFC2069,在没有qop选项时使用。
算法：(以MD5算法为例)
KD(H(A1), (nonce) : H(A2))
= MD5(MD5(A1) : (nonce) : MD5(A2))
= MD5(MD5((user) : (realm) : (password)) : (nonce) : MD5((request-method) : (uri-directive-value)))
（3）新摘要算法
新摘要算法为推荐方式，包含了对随机数计算和对称认证的支持。只要qop为auth或auth-int，就要使用这种方式。
算法：(以MD5算法，qop=auth-int为例)
KD(H(A1), (nonce) : (nc) : (cnonce) : (qop) : H(A2))
= MD5(MD5(A1) : (nonce) : (nc) : (cnonce) : (qop) : MD5(A2))
= MD5(MD5((user) : (realm) : (password)) : (nonce) : (nc) : (cnonce) : (qop) : MD5((request-method) : (uri-directive-value) : MD5((entity-body))))
例如，服务器response如下：
Authorization: Digest
username=”hu”
realm=”home”
nonce=”1” //服务器端的随机数一起带回
uri=”/login” //必须跟请求行一致
qop=”auth-int” //保护质量参数
nc=0000001//nonce-count随机数计数
cnonce=”3” //客户端随机数，用于对称校验
response=”XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX”//最终摘要
response计算公式为 ：
MD5(MD5(hu:home:(password)):1:0000001:3:auth:MD5(login:MD5(body)))
http权威指南中似乎未对nc做说明，引用RFC2831中的一段说明：
The nc-value is the hexadecimal count of the number of requests (including the current request) that the client has sent with the nonce value in this request. For example, in the first request sent in response to a given nonce value, the client sends "nc=00000001". The purpose of this directive is to allow the server to detect request replays by maintaining its own copy of this count - if the same nc-value is seen twice, then the request is a replay...
试着翻译下：
nc-value指的是客户端向服务器端发送带有随机数的请求次数（包含本次请求）的十六进制数(补充：八位十六进制数)。例如，当第一次发送带有随机数的请求时，客户端发送”nc=00000001”。其目的是让服务器能够通过维护请求次数，检测到重复请求-如果相同的nc-value出现在两次请求中，那么这两次请求即为重复请求...
参考：https://www.ietf.org/rfc/rfc2... 搜索nonce-count
（4）机数选择
RFC2617建议采用的随机数公式：
Base64(time-stamp H(time-stamp : ETag : private-key))
以服务器端为例：time-stamp为服务器响应请求的时间；ETag为请求实体有关的Http ETag首部（详见浏览器缓存之协商缓存ETag）；private-key是只有服务器知道的字符串。保证不同请求时间，不同文件，产生不同随机数。
（5）对称认证
在客户端接收到服务器端发回401响应后，可以在发送授权请求的Authorization header中加上客户端随机数，这就要求服务器端再收到第二次请求时，将客户端随机数加入算法。
（6）请求摘要 & 响应摘要
响应摘要的计算方式与请求摘要类似，但响应中没有方法，报文实体数据也不同，这些信息影响A2的计算结果：
请求摘要(QoP=auth-int)：A2=(request-method) : (uri-directive-value) : H((request-entity-body))
响应摘要(QoP=auth-int)：A2=:(uri-directive-value) : H((response-entity-body))
