Http用户认证

计算机无法判断使用者的身份，服务器无法判断网络另一头是什么。因此，为了知道是谁在访问服务器，需要让客户端自报家门。
服务器核对的不是是否为本人，而是核对“登录者本人才知道的信息”或者“登录者本人才会拥有的信息”，譬如如下：
- 密码：本人才会知道的字符串信息；
- 动态令牌：本人持有的设备内显示的一次性密码；
- 数字证书：本人或中断持有的信息；
- 生物认证：指纹，或者虹膜等；
- IC卡等：本人才持有的信息；
- ……

HTTP1.1使用的认证方式有如下几种：

BASIC认证

Basic认证时Http/1.0就定义的认证方式，是Web服务器与通信客户端之间进行的认证方式。
认证步骤如下：
1. 客户端发送请求；
2. 服务器端返回状态码401（Authorization Required）告诉客户端需要进行认证；响应包含首部字段WWW-Authenticate，包括认证方式（BASIC）以及Request-URI安全域字符串（realm）；
3. 客户端将用户ID和密码以冒号连接后以Base64的方式编码后发送（放到Authorization首部字段中）；如果客户端是浏览器，浏览器会自动完成Base64的编码转换工作；
4. 认证成功则返回状态码200，否则返回状态码401；

bool YunService::getAccessTokenByOAuth2(const QString &userName, const QString &password,
                                        QString &token, qint64 &expireIn)
{
    // 发起httppost请求
    QNetworkRequest oRequest;
    oRequest.setRawHeader("Authorization", buildCredential().toLocal8Bit());
    oRequest.setRawHeader("Content-type", "application/x-www-form-urlencoded");
    oRequest.setUrl(QUrl(ACCESSTOKEN_URL));
    QByteArray oRequestBody = buildRequestBody(userName, password);

QString YunService::buildCredential()
{
    QByteArray sCode = QByteArray(APP_KEY) + ":" + QByteArray(APP_SERCRET);
    sCode = sCode.toBase64();
    return "Basic " + sCode;
}

Basic采用的Base64编码，并不是加密处理，可以明文解码。
另外，一般浏览器无法实现Basic方式的认证注销操作。

DIGEST认证

Http/1.1开始有了DIGEST认证。
DIGEST认证也采用质询/响应（Chanllenge/Response）的方式，但不会像BASIC认证那样直接发送明文密码。
质询/响应：一方先发送认证要求给另一方，然后使用另一方发送来的质询码计算生成响应码，最后将响应码返回给对方进行认证。
由于发送的仅仅是响应摘要以及由质询码产生的计算结果，所以比起Basic认证，密码泄露的可能性降低了。
认证步骤如下：
1. 客户端发送请求；
2. 服务器端发送临时质询码（随机数nonce），并返回401；
返回的首部包含WWW-Authenticate字段，内容包括认证方式Digest，以及安全域字符串realm；同时该首部中海包含nonce随机数字符串，以及对应的algorithm等；
3. 客户端发送响应码：在Authorization首部中，包含认证方式Digest，用户名，realm，质询码，algorithm，响应码，uri等；
4. 服务器接收到Authorization，会确认消息的正确性；认证通过则返回包含Request-URI资源的响应；
DIGEST认证高于BASIC认证的安全等级，但和HTTPS相比依旧很弱。
DIGEST认证提供防治密码被窃听的保护机制，但不存在防止用户伪装的保护机制。

SSL客户端认证

利用SSL可以避免用户名和密码被盗的情况的发生，即防止冒充。
SSL客户端认证是借由HTTPS的客户端证书完成认证的方式。凭借客户端证书认证，服务器可以确认访问是否是来自于已经登录的客户端。
为了使用SSL客户端认证，需要事先将客户端证书分发给客户端，并且客户端必须安装此证书。
认证步骤如下：
- 客户端发送认证请求，服务器端发送Certificate Request报文，要求客户端提供证书；
- 用户选择将发送的客户端证书后，客户端会把证书信息以Client Certificate报文方式发送给服务器；
- 服务器验证客户端证书，通过后可以领取证书内客户端的公开密钥，然后开始HTTPS加密通信。
双因素认证：
- 第一个认证因素是SSL客户端证书，用来认证客户端计算机；
- 第二个认证因素是密码，用来确定是用户本人的行为；
客户端证书需要支付一定的费用才能使用，主要是指从认证机构购买客户端证书的费用，以及服务器运营者为了保证自己搭建的认证机构安全运行所产生的费用。

基于表单认证

基于表单的认证方法并不是在HTTP协议中定义的。
客户端会向服务器上的Web应用程序发送登录信息（Credential），按登录信息的验证结果认证。根据Web应用程序的实际开发，提供的界面以及认证方式各不相同。
比如SSH和FTP协议，服务器与客户端之间的认证时合乎标准规范的，并且满足了最基本的功能需求之上的安全使用级别，因此这些协议的认证可以拿来直接使用。
基于表单认证的标准规范还没有定论，一般会使用Cookie来管理Session。
基于表单认证本身是通过服务器端的Web应用，将客户端发送来的用户ID和密码与之前登录过的信息做匹配来进行认证。

由于HTTP是无状态协议，无法实现状态管理，因此要使用Cookie来管理Session，以弥补Http协议中不存在的状态管理功能。
步骤如下：
- 客户端发送登录信息（用户ID，密码）；
- 服务器发送包含Session ID（JSESSIONID…）的Cookie，在Set-Cookie首部字段中包含，同时记录客户端的登录状态；
- 客户端再行请求时，同时发送包含SessionID的Cookie信息；
注意：
- 要保管好SessionID，防止被盗；
- 为减轻跨站脚本攻击XSS造成的损失，事先在Cookie内加入httponly属性；
- 服务器端的密码保存，先给密码加盐Salt的方式增加额外信息，再使用散列函数计算出散列值后保存。