身份验证是判断客户端是否有资格访问资源的过程。HTTP 协议支持将身份验证作为协商访问安全资源的一种方式。
来自客户端的初始请求通常是匿名请求，不包含任何身份验证信息。 HTTP 服务器应用程序可以拒绝匿名请求，而同时指示必须进行身份验证。
服务器应用程序发送 WWW-Authentication 头来指示受支持的身份验证方案。
HTTP/1.1 使用认证方式如下：
- BASIC 认证(基本认证)
- DIGEST 认证(摘要认证)
- SSL 客户端认证
- FormBase 认证(基于表单认证)
BASIC 认证
BASIC 认证是从 HTTP/1.0 就定义的认证方式，其主要流程主要分为下面3步：
- 当客户端请求的资源需要 BASIC 认证，服务器会随状态码
401 Authorization Required，返回带WWW-Authenticate首部字段的响应； - 客户端接收到 401 状态码后，为了通过认证，需要将用户 ID 及密码发给服务器。发送的内容是由用户 ID 和密码构成，两者中间以
:连接后，再经过 Base64 编码处理； - 接收到包含首部字段
Authorization请求的服务器，会对认证信息的正确性进行验证。如验证通过，则返回一条包含Request-URI资源的响应。
缺陷
- Base64 编码方式不是一种加密处理，攻击者不需要借助什么就可以对其解码；
- 一般浏览器无法实现 BASIC 认证注销操作。
总结
因其在使用上不够便捷，也达不到多数 Web 网站想要的安全性，所以 BASIC 认证不常用。
DIGEST 认证
DIGEST 认证使用和 BASIC 一样的 质询 / 响应 方式，两者的区别在于前者不像 BASIC 认证那样直接发送明文密码。
质询响应方式是指，发送方会先发送认证要求给接收方，接着发送方使用从接收方那接收到的质询码计算生成响应码。最后将响应码返回给接收方进行认证的方式。
其主要流程分为下面3步：
客户端请求需认证的资源时，会向服务器发送认证请求，服务器会随状态码 401，返回带
WWW-Authenticate首部字段的响应。该字段内包含质问响应方式认证所需的临时质询码（随机数，nonce）；客户端接收到 401 状态码后，返回的响应中包含
DIGEST 认证必须的首部字段Authorization信息(首部字段Authorization内必须包含username、realm、nonce、uri和response的字段信息。)；- 服务器接收到包含首部字段
Authorization请求后，会确认认证信息的正确性。认证通过后则返回包含Request-URI资源的响应。
总结
DIGEST 认证 提供了高于 BASIC 认证 安全等级，不过和后者一样使用上不便捷灵活，同时 DIGEST 认证 提供防止密码被窃听的保护机制，但不能防止用户伪装，仍达不到多数 Web 网站对安全要求，所以适用范围仍然有限。
SSL 客户端认证
SSL 认证是借由 HTTPS 的客户端证书认证的方式。凭借客户端证书认证，服务器可确认访问是否来自已登录的客户端。
SSL 认证步骤：
为达到 SSL 客户端认证的目的，需要事先将客户端证书分发给客户端，且客户端必须安装此证书。
服务器在接收到客户端需要认证资源的请求后，会发送 Certificate Request 报文（要求客户端提供客户端证书）；
用户选择将发送的客户端证书后，客户端会把客户端证书信息以
Client Certificate报文方式发送给服务器；服务器验证客户端证书验证通过后方可领取证书内客户端的公开密钥，然后开始 HTTPS 加密通信。
SSL 客户端认证采用的双因素认证
在多数情况下，SSL 客户端认证 不仅依靠证书完成认证，一般还会与 基于表单认证 组合形成一种 双因素认证。
简单来说，证书认证是用来认证客户端计算机的，基于表单认证是用来确定是用户本人的行为。
基于表单认证
基于表单认证 并不是在 HTTP 协议中定义的。不过目前的认证多半为基于表单认证。
由于便利性和安全性问题，HTTP 协议标准提供的 BASIC 认证和 DIGEST 认证几乎不怎么使用，另外 SSL 客户端认证，因为导入及维持费用尚未普及。
Session 管理及 Cookie 应用
基于表单认证本身是通过服务器端的 Web 应用，将客户端发送过来的用户 ID 和密码与之前登录过的信息做匹配来进行认证的。
因为 HTTP 是无状态协议，所以我们会使用 Cookie 来管理 Session(会话)，来弥补 HTTP 协议中不存在的状态管理功能。
步骤
客户端把用户 ID 和密码等信息放入报文实体部分通常以
POST方式发送请求到服务器；服务器会发放用来识别用户的
Session ID。通过验证从客户端发送过来的登录信息进行身份认证，然后把用户的认证状态与Session ID绑定后记录在服务器端；客户端接收
Session ID后，会将其作为Cookie保存在本地。下次向服务器发送请求时，浏览器会自动发送Cookie，所以Session ID也会随之发送到服务器。服务器端可通过验证接收到的Session ID识别用户和其认证状态。
扩展
由于 Session ID 也有被盗走的可能，所以 Session ID 应使用难以推测的字符串，且服务器也需要进行有效期的管理，保证其安全性。
此外通常，给密码加盐(salt) 的方式增加额外信息，再使用散列 (hash) 函数计算出散列值后保存。
salt其实就是由服务器随机生成的一个字符串，但是要保证长度足够长，并且是真正随机生成的。然后把它和密码字符串相连接（前后都可以）生成散列值。
当两个用户使用了同一个密码时，由于随机生成的salt值不同，对应的散列值也将是不同的。这样一来，很大程度上减少了密码特征，攻击者也就很难利用自己手中的密码特征库进行破解。