某些Web页面只想让特定的人浏览，为达到这个目标，必不可少的就是认证功能。
何为认证
为了弄清究竟是谁在访问服务器，就得让对方的客户端自报家门。
-
核对的信息通常如下：
- 密码：只有本人才会知道的字符串信息
- 动态令牌：仅限本人持有的设备内显示的一次性密码
- 数字证书：仅限本人持有的信息
- 生物认证：指纹和虹膜等本人的生理信息
- IC 卡等：仅限本人持有的信息
-
HTTP使用的认证方式：
- BASIC 认证（基本认证）
- DIGEST 认证（摘要认证）
- SSL 客户端认证
- FormBase 认证（基于表单认证）
BASIC 认证
BASIC 认证（基本认证）是从 HTTP / 1.0 就定义的认证方式。即便是现在仍有一部分的网站会使用这种认证方式。是 Web 服务器与通信客户端之间进行的认证方式。
-
当请求的资源需要 BASIC 认证时，服务器会返回状态码 401 Authorization Required，并返回带 WWW-Authenticate 首部字段的响应。该字段内包含认证的方式（BASIC）及 Request-URI 安全域字符串（realm）。
-
接收到状态码 401 的客户端为了通过 BASIC 认证，需要将用户 ID 及密码发送给服务器。发送的字符串内容是由用户ID : 密码经过 Base64 编码处理后的。浏览器会自动完成明文到 Base64 编码的转换。
-
接收到包含首部字段 Authorization 请求的服务器，会验证信息的正确性，如验证通过，返回一条包含 Request-URI 资源的响应。
缺陷：
- BASIC 认证虽然采用 Base64 编码方式，但这不是加密处理，不需要任何附加信息即可对其解码。
- 除此之外想再进行一次 BASIC 认证时，一般浏览器也无法实现认证注销操作。
- BASIC 认证并不常用，不灵活，达不到多数 Web 网站期望的安全性等级。
DIGEST 认证
DIGEST认证同样使用质询/响应的方式（challenge / response），但不会像 BASIC 认证那样直接发送明文密码。
质询响应方式：一开始一方会先发送认证要求给另一方，接着使用从另一方那接收到的质询码计算生成响应码。最后将响应码返回给对方进行认证的方式。
因为发送给对方的只是响应摘要及由质询产生的计算结果，所以密码泄露的可能性就降低了。
-
请求需认证的资源时，服务器会随着状态码 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 认证提供防止密码被窃听和保护机制，但并不存在防止用户伪装的保护机制。
- DIGEST 认证和 BASIC 认证一样，使用上不灵活，却仍达不到多数 Web 网站对高度安全等级的追求标准，因此它的适用范围也有所限制。
SSL 客户端认证
从使用用户 ID 和密码的认证方式方面来讲，只要二者的内容正确，即可认证是本人的行为。但如果用户 ID 和密码被盗，就很有可能被第三者冒充。利用 SSL 客户端认证则可以避免该情况的发生。
SSL 客户端认证是借由 HTTPS 的客户端证书完成认证的方式。凭借客户端证书（详见 HTTPS加密机制以及数字证书）认证，服务器可确认访问是否来自已登陆的客户端。
SSL 客户端认证步骤：
为达到 SSL 客户端认证的目的，需要事先将客户端证书分发给客户端，且客户端必须安装此证书。
-
接收到需要认证资源的请求，服务器会发送 Certificate Request 报文，要求客户端提供客户端证书。
-
用户选择将发送的客户端证书后，客户端会把客户端证书信息以 Client Certificate 报文方式发送给服务器。
-
服务器验证客户端证书，验证通过后方可领取证书内客户端的公开密钥，然后开始 HTTPS 加密通信。
SSL 客户端认证采用双因素认证
一般的，SSL 客户端认证不仅依靠证书完成认证，一般会和基于表单认证组合形成一种双因素认证来使用。
双因素认证：认证过程中不仅需要密码这一个因素，还需要申请认证者提供其他特有信息，从而作为另一个因素，与其组合使用的认证方式。
换言之，第一个认证因素的 SSL 客户端证书用来认证客户端计算机，另一个认证因素的密码则用来确定这是用户本人的行为。通过双因素认证后，就可以确认是用户本人正在使用匹配正确的计算机访问服务器。
SSL 客户端认证必要的费用：
- 从认证机构购买客户端证书的费用
- 服务器运营者为保证自己搭建的认证机构安全运营所产生的费用
- 服务器运营者也可以自己搭建认证机构，但要维持安全运行就会产生相应的费用
基于表单认证
基于表单的认证方法并不是在 HTTP 协议中定义的，客户端会向服务器上 Web 应用发送登录信息，按登录信息的验证结果认证。
认证多半为基于表单认证
-
由于使用上的便利性及安全性问题，HTTP 协议标准提供的 BASIC 认证和 DIGEST 认证几乎不怎么使用。另外，SSL 客户端认证虽然具有高度的安全等级，但因为导入及维持费用等问题，还尚未普及。
-
比如 SSH 和 FTP 协议，服务器与客户端之间的认证是合乎标准规范的，并且满足了最基本的功能需求上的安全使用级别，因此这些协议的认证可以拿来直接使用。但是对于 Web 网站的认证功能，能够满足其安全使用级别的标准规范并不存在，所以只好使用由 Web 应用程序各自实现基于表单的认证方式。
详情请看：
Session 管理及 Cookie 应用
网友评论