某些 Web 页面只想让特定的人浏览，或者干脆仅本人可见。为达到这个目标，必不可少的就是认证功能。

何为认证

计算机本身无法判断坐在显示器前的使用者的身份，为了弄清究竟是谁在访问服务 器，就得让对方的客户端自报家门。

核对的信息通常是指：

  • 密码：只有本人才会知道的字符串信息
  • 动态令牌：仅限本人持有的设备内显示的一次性密码。
  • 数字证书：仅限本人（终端）持有的信息
  • 生物认证：指纹和虹膜等本人的生理信息
  • IC 卡等：仅限本人持有的信息。

image.png

HTTP 使用的认证方式

HTTP/1.1 使用的认证方式

  • BASIC 认证（基本认证）
  • DIGEST 认证（摘要认证）
  • SSL 客户端认证
  • FormBase 认证（基于表单认证）

BASIC 认证

BASIC 认证（基本认证）是从HTTP/1.0就定义的认证方式。即便是现在仍有一部分的网站会使用这种认证方式。

认证步骤
image.png

  • 当请求的资源需要 BASIC 认证时，服务器会随状态码 401 Authorization Required，返回带 WWW-Authenticate 首部字段的响应。 该字段内包含认证的方式（BASIC） 及 Request-URI 安全域字符串 （realm）。
  • 接收到状态码 401 的客户端为了通过 BASIC 认证，需要将 用户 ID 及密码发送给服务器。发送的字符串内容是由用户 ID 和密码 构成，两者中间以冒号（:）连接后，再经过 Base64 编码处理
    • 字符串写入首部字段 Authorization 后， 发送请求。
    • 当用户代理为浏览器时，用户仅需输入用户 ID 和密码即可，之后， 浏览器会自动完成到 Base64 编码的转换工作。
  • 接收到包含首部字段Authorization请求的服务器，会对认证信息的正确性进行验证。如验证通过，则返回一条包含 Request-URI 资源的响应。

BASIC 认证虽然采用Base64编码方式，但这不是加密处理。不需要任何附加信息即可对其解码。

DIGEST 认证

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

所谓质询响应方式是指：

  • 一开始一方会先发送认证要求给另一方
  • 接着使用从另一方那接收到的质询码计算生成响应码。
  • 最后将响应码返回给对方进行认证的方式。

image.png

因为发送给对方的只是响应摘要及由质询码产生的计算结果，所以比起 BASIC 认证，密码泄露的可能性就降低了。

认证步骤
image.png

  • 请求需认证的资源时，服务器会随着状态码 401 Authorization Required，返 回带 WWW-Authenticate 首部字段的响应。该字段内包含质问响应方式认证所需的临时质询码（随机数， nonce）。
    • 首部字段 WWW-Authenticate 内必须包含 realm 和 nonce 这两个字段的信息。
    • nonce 是一种每次随返回的401响应生成的任意随机字符串。该字符串通常推荐由 Base64编码的十六进制数的组成形式，但实际内容依 赖服务器的具体实现。
  • 接收到 401 状态码的客户端，返回的响应中包含DIGEST认证必须的首部字段 Authorization信息。
    • 首部字段 Authorization 内必须包含 username、realm、nonce、uri 和 response 的字段信息。
    • 其中，realm 和 nonce 就是之前从服务器接收到 的响应中的字段。
    • username 是 realm 限定范围内可进行认证的用户名。
    • uri（digest-uri）即 Request-URI 的值，但考虑到经代理转发后 Request-URI 的值可能被修改，因此事先会复制一份副本保存在 uri 内。
    • response 也可叫做 Request-Digest，存放经过 MD5 运算后的密码字符 串，形成响应码
  • 接收到包含首部字段Authorization请求的服务器，会确认认证信息的正确性。认证通过后则返回包含 Request-URI 资源的响应。
    • 这时会在首部字段 Authentication-Info 写入一些认证成功的相关信息。

DIGEST 认证提供了高于BASIC认证的安全等级，但是和HTTPS的客户端认证相比仍旧很弱。DIGEST 认证提供防止密码被窃听的保护机制，但并不存在防止用户伪装的保护机制。

SSL 客户端认证

SSL客户端认证是借由 HTTPS的客户端证书完成认证的方式。凭借客户端证书认证，服务器可确认访问是否来自已登录的客户端。

SSL 客户端认证的认证步骤

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

SSL 客户端认证采用双因素认证

在多数情况下，SSL客户端认证不会仅依靠证书完成认证，一般会和基于表单认证（稍后讲解）组合形成一种双因素认证（Two-factor authentication）来使用。

所谓双因素认证就是指，认证过程中不仅需要密码这一个因素，还需要申请认证者提供其他持有信息，从而作为另一个因素，与其组合使用的认证方式

  • 第一个认证因素的 SSL客户端证书用来认证客户端计算机，
  • 另一个认证因素的密码则用来确定这是用户本人的行为。

通过双因素认证后，就可以确认是用户本人正在使用匹配正确的计算机访问服务器。

基于表单认证

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

认证多半为基于表单认证

由于使用上的便利性及安全性问题，HTTP 协议标准提供的 BASIC 认 证和 DIGEST 认证几乎不怎么使用。另外，SSL客户端认证虽然具有高度的安全等级，但因为导入及维持费用等问题，还尚未普及。

对于 Web 网站的认证功能，能够满足其安全使用级别的标准规范并不存在，所以只好使用由 Web 应用程序各自实现基于表单的认证方式。

基于表单认证的标准规范尚未有定论，一般会使用 Cookie 来管理 Session（会话）。

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

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

image.png

  • 客户端把用户 ID 和密码等登录信息放入报文的实体部分，通常是以POST方法把请求发送给服务器。而这时，会使用HTTPS通信来进行HTML表单画面的显示和用户输入数据的发送
  • 服务器会发放用以识别用户的 Session ID。通过验证从客户端发送过来的登录信息进行身份认证，然后把用户的认证状态与 Session ID 绑定后记录在服务器端
    • 向客户端返回响应时，会在首部字段 Set-Cookie 内写入 Session ID
    • Session ID 是一种用以区分不同用户的等位号
    • 如果 Session ID被第三方盗走，对方就可以伪装成你的身份进行恶意操作了。因此必须防止 Session ID 被盗，或被猜出。为了做到 这点，Session ID应使用难以推测的字符串，且服务器端也需要进行有效期的管理，保证其安全性
    • 为减轻跨站脚本攻击（XSS）造成的损失，建议事先在 Cookie 内加上 httponly 属性。
  • 客户端接收到从服务器端发来的 Session ID后，会将其作为Cookie保存在本地。下次向服务器发送请求时，浏览器会自动发送 Cookie，所以 Session ID 也随之发送到服务器。服务器端可通过验证接收到的 Session ID 识别用户和其认证状态。

另外，不仅基于表单认证的登录信息及认证过程都无标准化的方法，服务器端应如何保存用户提交的密码等登录信息等也没有标准化。通常，一种安全的保存方法是，先利用给密码加盐（salt）的方式增加额外信息，再使用散列（hash）函数计算出散列值后保存。