某些Web页面只想让特定的人浏览，为达到这个目标，需要认证功能。

8.1 何为认证

计算机需要核对信息才能弄清访问服务器的人是谁，核对信息通常有密码、动态令牌等。

HTTP/1.1使用的认证方式：

  • BASIC认证(基本认证)
  • DIGEST认证(摘要认证)
  • SSL客户端认证
  • FromBase认证(基于表单认证)

8.2 BASIC认证

从HTTP/1.0就存在了。
image.png
认证步骤：

  1. 当请求的资源需要BASIC认证时，服务器会随状态码401 Authorization Required返回带有WWW-Authenticate首部字段的响应。该字段包含认证的方式(BASIC)和Request-URI安全域字符串。
  2. 接收到状态码401的客户端为了通过BASIC认证，需要将用户ID和密码发送给服务器。发送的字符串内容由用户ID和密码构成，两者中间以冒号(：)连接后，再经过Base64编码处理。image.png
  3. 接收到包含首部字段Authorization请求的服务器，会验证认证信息的正确性。如果验证通过则返回一条包含Request-URI资源的响应。BASIC认证虽然采用Base64编码方式，但这不是加密处理。不需要任何附加信息即可实现解码。

BASIC认证使用上不够便捷灵活，且达不到多数Web网站期望的安全性等级，因此它并不常用。

8.3 DIGEST认证

为了弥补BASIC认证的弱点，从HTTP/1.1起就有了DIGEST认证。它同样采用质询/响应的方式，但不会像BASIC认证那样直接发送明文密码。

质询/响应方式是指：一开始一方会先发送认证要求给另一方，接着使用从另一方那接受到的质询码计算生成响应码。最后将响应码返回给对方进行认证。
image.png
因为发送给对方的只是响应摘要及由质询码产生的计算结果，所以比起BASIC认证，密码泄露的可能性降低了。

认证步骤：
image.png

  1. 请求需认证资源时，服务器会伴随状态码401 Authorization Required返回带有WWW-Authenticate首部字段的响应。该字段内包含质询响应认证所需的临时质询码(随机数，nonce)。该首部字段内必须包含**realm**和**nonce**这两个字段的信息。客户端就是依靠向服务器回送这两个值进行认证的。
  2. 接收到401状态码的客户端，返回的响应中包含DIGEST认证必须的首部字段Authorizaton信息。该首部字段内必须包含**username**、**realm**、**nonce**、**uri**和**response**等字段信息(其中realm和nonce是之前从服务器接受到的响应中的字段)。**username**、**realm**是限定范围内可进行认证的用户名。uri即Request-Digest的值，考虑到经代理转发后的值可能被修改，所以是先复制一份保存在uri中。response存放经过MD5运算后的结果密码字符串，形成响应码。
  3. 接收到包含首部字段Authorization请求的服务器，会确认认证信息的正确性。认证通过则返回包含Request-URI资源的响应，并在首部字段Authentication-Info写入一些认证成功的信息。

但是DIGEST认证依然不便捷灵活，而且达不到多数Web网站的安全需求，所以适用范围受限。

8.4 SSL客户端认证

从使用用户ID和密码的认证方式来说，只要二者内容正确即可认定为本人。但是如果ID和密码被盗，就会被冒充。利用SSL客户端认证则可以避免。

SSL客户端认证步骤：
为了达到SSL客户端认证的目的，需要事先将客户端证书分发给客户端，且客户端必须安装此证书。

  1. 接收到需要认证资源的请求，服务器会发送Certificate Request报文，要求客户端提供客户端证书。
  2. 用户选择将发送的客户端证书后，客户端会把客户端证书信息以Clent Certificate报文方式发给服务器。
  3. 服务器验证客户端证书通过后，领取证书内客户端的公开密钥，然后开始HTTPS加密通信。

8.5 基于表单认证 Session

基于表单的认证方法不是在HTTP协议中定义的。客户端会向服务器上的Web应用程序发送登录信息，栈登录信息的验证结果认证。

认证多半为表单认证，因为BASIC认证和DIGEST认证几乎不使用，SSL客户端认证费用较高。

Session管理及Cookie应用

一般使用Cookie来管理Session(会话)，作为基于表单认证的标准规范。

基于表单认证本身是通过服务器端的Web应用，将客户端发送来的ID和密码与之前登录过的信息做匹配来进行认证。

但是HTTP是无状态协议，之前已认证成功的用户状态无法通过协议层面保存。即，无法实现状态管理。因此即使当该用户下一次继续访问，也无法区分他与其他用户。所以使用Cookie来管理Session，以弥补HTTP协议中不存在的状态管理功能。
image.png

  1. 客户端把ID和密码放入报文的实体部分，通常以POST方法把请求发送给服务器。
  2. 服务器发放用于识别用户的 Session ID。通过验证登录信息进行身份认证，然后把用户的认证状态和Session ID 绑定后记录在服务器端。向客户端返回响应时，会在首部字段**Set-Cookie**中写入Session ID。为减轻跨站脚本攻击(XSS)的损失，建议事先在 Cookie 内加上 httponly 属性。
  3. 客户端接收到 Session ID 后，会将其作为 Cookie 保存在本地。下次向服务器发送请求时，浏览器自动发送 Cookie，所以 Session ID 也随之发送到服务器。服务器端可通过验证接受到的 Session ID 识别用户和认证状态。