摘要认证是什么？

对于普通的非敏感数据，我们更多关注其真实性和准确性，因此，如何在通信过程中保障数据不被篡改，首当其冲成为需要考虑的问题。鉴于使用HTTPS2性能上的成本以及需要额外申请CA证书，在这种情况下，一般采用对参数和响应进行摘要的方法，即能够满足需求。

针对每次请求和响应，按照一定的规则生成数字摘要，数字摘要需要涵盖客户端与服务端通信的内容，以及双方约定好的“盐”，以此来保障请求与响应不被第三方篡改。常见的摘要算法包括MD5、SHA等，关于摘要算法的介绍，前面章节已有详细介绍，此处便不再赘述。由于传递端和接收端都认为HTTP协议的请求参数是无序的，因此客户端与服务端双方需要约定好参数的排序方式。请求的参数经过排序后，再将参数名称和值经过一定的策略组织起来，加上一个密钥secret，也就是所谓的“盐”，然后通过约定的摘要算法生成数字摘要，传递给服务端。

在服务端接收到客户端传递的参数后,服务端会采用与客户端相同的策略对参数进行排序,并且加上相同的secret，采用相同的摘要方式生成摘要串。由于相同内容经过相同的摘要算法，生成的摘要内容必定是相同的。将服务端生成的摘要串与客户端生成摘要串进行比较，这样可以得知参数内容是否被篡改。同样的，服务端返回的响应也需要加上 secret，采用约定好的摘要算法生成相应的摘要，并将生成的摘要作为响应的一部分，返回给客户端，以便验证服务端返回数据的合法性。

当客户端接收到服务端的响应后，加上相同的secret进行拼接，并采用与服务端相同的摘要算法进行摘要，生成的摘要串与服务端传递过来的摘要串进行比较，这样便可得知服务端的响应是否被篡改。

由于摘要算法的不可逆性，并且大部分情况下不同的请求参数会有不同的服务端响应，鉴于参数和响应的多变性，摘要认证这种方式能够在一定程度上防止信息被篡改，保障通信的安全。但是,摘要认证的安全性取决于secret的安全性,由于服务端与客户端采用的是相同的secret,一旦secret泄露，通信的安全则无法保障。

我们平时在打开网页时或者在用浏览器访问你局域网的路由器时，经常会出现弹出登陆页面框要进行登陆授权后才能继续访问。比如如下提示：

上面图片展示的一个场景是客户端在使用HTTP协议和服务端通信时，服务器需要对客户端进行授权认证，客户端输入正确的用户密码后才能继续进行访问。那这个流程是如何实现的呢？

1.客户端请求需要授权认证的URL地址。

2.服务端返回401，告诉客户端这个请求需要授权认证，并且指定授权认证的方式。（在IE中系统会弹出对话框让输入用户和密码）

3.客户端按服务器要求的授权方式，拼装用户和密码，放入到请求头中，并再次发送。

4.服务端根据提供用户的密码，来决定返回成功还是失败。

我们称上面这种授权认证机制叫challange/response机制，客户端发起请求，服务器发起挑战(challange)，客户端接收挑战，服务器返回挑战结果。

在HTTP协议1.0系统中只支持：基本认证(Basic realm)，而在1.1中支持摘要认证:(Digest realm)，和WSSE(WS-Security)认证 至于使用什么认证由服务端在返回的401响应中的 WWW-Authenticate 中指定。

1.基本认证(Basic realm)方式下，客户端接受挑战的方式是用: BASE64(用户:密码)的结果返回给服务端。这种方法比较简单，而且在网络传输中很容易被破解。上面的例子用的就是基本认证方式，这时候客户端只需要在请求头中带上：

Authorization: [认证的方式] [BASE64(用户:密码)]

2.摘要认证(Digest realm)方式下，服务端在响应401时会返回一个随机数。 客户端 把MD5(用户，密码，随机数）后的值，连同用户一起通过Authorization: 请求头发送给服务端。服务端则根据用户取出对应的密码，随机数同样用MD5(用户，密码，随机数)， 如果两者相等则认为认证通过，否则认证失败。 查看具体交互过程

3.WSSE(WS-Security)认证。主要用于webservice服务的授权认证，具体请参考 WSSE

4.对于我们有时候访问第三方需要授权的资源时，我们采用OAuth协议来让第三方进行授权认证，因此在我们没有登录前，访问这些资源时服务端也可以返回401。同时它还带了如下的响应：

WWW-Authenticate: OAuth realm=<your_realm>

这样客户端就知道这种资源是需要OAuth认证的，这时候客户端应该启用Aauth认证机制，也就是OAuth协议可以用http认证的扩展来传输各种数据，也可以自己定义post方式来进行传输，具体参考OAUTH协议。

---