八、确认访问用户身份的认证
1、认证：服务器无法判断访问自己的是谁，需要核对“登陆者本人才知道的信息”、“登陆者本人才会有的信息”。
核对的信息通常包括密码、动态令牌、数字证书、生物认证、IC卡等。
但是只要能通过用户验证，即使不是本人，计算机也会默认是本人。
HTTP使用的认证方式：
（1）BASIC认证（基本认证）
（2）DIGEST认证（摘要认证）
（3）SSL客户端认证
（4）FormBase认证（基于表单认证）
2、BASIC认证
是从HTTP/1.0就定义的认证方式，是web服务器与通信客户端之间进行的认证方式。
BASIC认证步骤：
步骤一：当请求的资源需要BASIC认证时，服务器会随状态码401，返回带WWW-Authenticate首部字段的响应。该字段内包含认证的方式及Request-URI安全域字符串。
步骤二：接收到状态码401的客户端为了通过BASIC认证，需要将用户ID及密码发送给服务器。发送的字符串内容是由用户ID和密码构成，两者中间以冒号连接后，在经过Base64编码处理。
步骤三：接收到包含首部字段Authorization请求的服务器，会对认证信息的正确性进行验证。如验证通过，则返回一条包含Request-URI资源的响应。
但是BASIC认证不对信息进行加密，容易被盗。而且浏览器无法实现认证注销操作，不够便捷灵活，所以并不常用。
3、DIGEST认证
DIGEST认证的存在是弥补了BASIC认证存在的弱点，所以不会直接发送明文密码。
DIGEST认证使用的是质询/响应的方式。一开始一方会先发送认证要求给另一方，接着使用从另一方那接收到的质询码计算生成响应码。最后将响应码返回给对方进行认证。
DIGEST认证步骤：
步骤一：请求需认证的资源时，服务器会随着状态码401放回带WWW-Authenticate首部字段的响应。该字段内包含质问响应方式认证所需的临时质询码（随机数，通常推荐由Base64编码的十六进制数的组成形式）。
首部字段WWW-Authenticate内必须包含realm和nonce这两个字段的信息。客户端就是依靠向服务器回送这两个值进行认证的。
步骤二：接收到401状态码的客户端，返回的响应中包含DIGEST认证必须的首部字段Authorization信息。
步骤三：接收到首部字段Authentication请求的服务器，会确认认证信息的正确性。认证通过后则返回包含Request-URI资源的响应。
但是DIGEST认证与BASIC认证一样都不便捷灵活，适用范围不广。
4、SSL客户端认证
SSL客户端认证是借由HTTPS的客户端证书完成认证的方式。凭借客户端证书认证，服务器可确认访问是否来自已登录的客户端。
SSL客户端认证步骤：
步骤一：接收到需要认证资源的请求，服务器会发送Certificate Request报文，要求客户端提供客户端证书。
步骤二：用户选择将发送的客户端证书后，客户端会把客户端证书信息以Client Certfivate报文方式发送给服务器。
步骤三：服务器验证客户端证书验证通过后方可领取证书内客户端的公开密钥，然后开始HTTPS加密通信。
多数情况下，SSL客户端会和基于表单认证组合形成一种双因素认证来使用，认证过程中不仅需要密码这一个因素，还需要申请认证者提供其他持有信息，从而作为另一个因素，与其组合使用的认证方式。
5、基于表单认证
客户端会向服务器上的web应用程序发送登录信息，按登录信息的验证结果认证。
由于以上三种认证方式并不常用，所以大多数web网站的认证都使用了基于表单认证。
但由于表单认证的标准规范尚未有定论，一般会使用Cookie来管理Session，以弥补HTTP协议中无状态的特性。
Session管理及Cookie应用认证步骤：
步骤一：客户端吧用户ID和密码等登录信息放入报文的实体部分，通常是以POST方法把请求发送给服务器。而这时，会使用HTTPS通信来进行HTML表单画面的显示和用户输入的数据发送。
步骤二：服务器会发放以识别用户的Session ID。通过验证从客户端发送过来的登录信息进行身份认证，然后把用户的认证状态与Session ID绑定后记录在服务器端。（为减轻跨站脚本攻击XXS造成的损失，建议在Cookie内加上httponly属性）
步骤三：客户端接收到从服务器端发来的Session ID后，会将其作为Cookie保存在本地。下次向服务器发送请求时，浏览器会自动发送Cookie，所以Session ID也随之发送到服务器，服务器端可通过验证接收到的Session ID识别用户和认证状态。