使用SHA256算法做HTTP摘要认证

使用SHA256算法做HTTP摘要认证

HTTP的认证分为两种，basic和digest，两种方法目前网上都有介绍，不过大家常用的还是digest认证，相比于basic而言，安全性还是要高一点的。不过digest认证目前在网上看到的资料都是针对RFC2617的，描述的都是MD5摘要算法，但是对于有些需求（比如客户要求更高的安全性，比如在某些公司直接就不让用MD5），这个时候MD5就不适用了，这种情况SHA算法就派上用场了，幸运的是RFC也出了这一标准RFC7616（the MD5 algorithm is still supported
but NOT RECOMMENDED.），我这边就简单描述一下SHA256在digest认证过程中的应用。

注：目前时间原因，没有亲自实操，只是看了点资料，这篇博客目前主要是对RFC7616做个解释，日后还要自己敲代码做验证，目前只能做参考，详细的摘要认证可以参考HTTP摘要认证。

HTTP摘要认证流程

• 客户端请求
• 服务器回应
• 客户端重新请求并附带Authorization域
• 服务器根据报头信息和数据信息进行认证

1，客户端请求
首先客户端发送request到服务器，这个request可以是一个对象访问，比如get一篇博客，也可以是一个软件自定义的功能请求，比如开发就定义这是个注册请求，收到这个请求就要做注册认证。

2，服务器回应
RFC定义的是，当服务器收到一个要对access-protected对象进行访问的request时，request若无Authorization header则服务器回应客户端401 Unauthorized状态码，并附带WWW-Authorization header。大致可能是这样的：

HTTP /1.1 401 Unauthorized
WWW-Authenticate:Digest
realm= ”test realm”
qop=auth,auth-int”
nonce=”66C4EF58DA7CB956BD04233FBB64E0A4”

事实上server的动作要怎么操作看开发自己定义（比如收到特定请求也回应401），但是要遵循标准。WWW-Authorization回应定义了摘要认证的整个scheme，它包含了许多字段，我就主要介绍几个：

realm: A string to be displayed to users so they know which username and password to use.
一般应该是这样的 "registered_users@example.com"。
nonce: A server-specified string which should be uniquely generated each time a 401 response is made. 就是server产生的一个随机数，一般可以根据时间戳来做这个。
algorithm: A string indicating an algorithm used to produce the digest and an unkeyed digest. 表明此次认证的摘要算法，如果没有，则默认使用MD5。

In this document, the string obtained by applying the digest 
algorithm to the data "data" with secret "secret" will be denoted
by KD(secret, data), and the string obtained by applying the  
unkeyed digest algorithm to the data "data" will be denoted
H(data).  KD stands for Keyed Digest, and the notation unq(X)
means the value of the quoted-string X without the surrounding
quotes and with quoting slashes removed.

For "<algorithm>" and "<algorithm>-sess"

       H(data) = <algorithm>(data)

and

       KD(secret, data) = H(concat(secret, ":", data))

For example:

For the "SHA-256" and "SHA-256-sess" algorithms

       H(data) = SHA-256(data)

后面的这点中文实在不好解释。。。
qop: This parameter MUST be used by all implementations. It is a
quoted string of one or more tokens indicating the "quality of
protection" values supported by the server. The value "auth"
indicates authentication; the value "auth-int" indicates
authentication with integrity protection. See the descriptions
below for calculating the response parameter value for the
application of this choice. Unrecognized options MUST be ignored.

3，客户端重新请求并且附带Authorization域
客户端收到401后，如果客户端是浏览器，则会弹出对话框，让用户输入用户名和密码，然后发送新的请求到服务器，不过此时请求中就带有Authorization header了。Authorization也有许多字段，这里也主要介绍其中的几个：
response: 计算出来的一个字符串，后面认证要用，如何计算的后面介绍。
username: 字符串表明当前用户名。
realm: 同上。
qop: 第二步中服务器回应中的WWW-Authorization中的qop中的一个。
cnonce: This parameter MUST be used by all implementations. The cnonce
value is an opaque quoted ASCII-only string value provided by the
client and used by both client and server to avoid chosen
plaintext attacks, to provide mutual authentication, and to
provide some message integrity protection. See the descriptions
below of the calculation of the rspauth and response values.

response的计算：
如果qop是auth或者auth-int：
response=<">(KD(H(A1),unq(nonce)":"nc":"unq(cnonce)":"unq(qop)":"H(A2))<">
当采用SHA256算法时，A1 = unq(username)":"unq(realm)":"passwd passwd是该用户的密码。
如果qop是auth或者没有定义，则A2=Method":"request-uri,如果qop是auth-int，则A2=Method":"request-uri":"H(entity-body)

4,服务器根据报头信息和数据信息进行认证
服务器收到了客户端的带有Authorization域的请求，则查找该username的密码，然后重新按照第三步的规则计算一遍response，然后和Authorization域中的response进行对比，如果一样，则认证成功，否则失败。

大致流程大概如上所示，不过写的非常简陋，还是强烈建议看RFC文档，标准定义其实写的非常详细。