tjhttp 六、《图解HTTP》- 用户身份认证
6.1 概览
常见的用户身份认证方式：
- 密码
- 动态令牌
- 数字证书
- 生物人证
- IC卡
在HTTP1.1中通常存在下面几种认证方式：
- BASIC认证（基本认证）：
- DIGEST认证（摘要认证）：
- SSL客户端认证
- FormBase认证（表单认证）
6.2 SSL认证
由于SSL认证是我们日常开发基础最多的的，所以首先来理解一下。
SSL是同时使用对称加密和非对称加密的方式，在链接的过程中使用非对称加密，而在连接之后使用对称加密，类似在两边先通过身份牌认识双方，然后用特定的通行证完成双方的通信。
安全套接字层 (SSL) 技术通过加密信息和提供鉴权，保护您的网站安全。一份 SSL 证书包括一个公共密钥和一个私用密钥。公共密钥用于加密信息，私用密钥用于解译加密的信息。浏览器指向一个安全域时，SSL 同步确认服务器和客户端，并创建一种加密方式和一个唯一的会话密钥。它们可以启动一个保证消息的隐私性和完整性的安全会话。
6.2.1 基本工作原理
对于SSL的认证方式，基本的流程如下（注意这里省略一步是客户端需要安装SSL证书）：
- 客户端发送请求，服务端接收到认证资源，同时发送Certificate Request报文，同时要求客户端提供证书。
- 用户选择客户端证书通过Client Certificate报文的方式传给服务器。
- 服务器验证客户端证书拿到客户端的密钥信息，之后开始HTTPS对称加密通信。
当然书中提到的模糊的交互过程，下面是关于SSL两种认证方式的区别和细节：
6.2.2 单向认证
单向认证在整个SSL握手流程中仅仅单向验证了服务器的SSL证书。因此这个单向认证过程使客户端浏览器可以连接到正确的网站服务器，并且仅通过安全连接将所有数据传输到目标站点。
- 客户端发送SSL协议版本号，加密算法，随机数等信息。
- 服务端给客户端回传客户端所发送的这一类信息，同时返回服务端的证书，也就是公钥证书。
客户端校验服务端证书的合法性，合法正确通信，否则停止通信并且警告，具体内容如下：
- 证书是否过期。
- 发行服务器CA可靠性。
- 返回公钥是否正确解开并且和服务器的实际域名匹配。
- 服务器证书域名是否和服务器的实际域名匹配。
- 客户端发送自己支持的加密方案，提供服务器选择。
- 服务器选择提供的加密方案中加密程度最高的方案。
- 服务器选好加密方案通过明文方式发给客户端。
- 客户端收到加密方案使用方案生成随机码，以此作为对称加密的密钥，服务端返回的公钥加密，加密后的随机码发给服务器。
- 服务端收到客户端的加密信息之后，用自己私钥解密并且对称加密密钥。服务端和客户端使用随机生成的密码进行对称加密，保证信息安全。
6.2.3 双向认证
主要的步骤和单向认证一致，这里仅仅介绍有差别的步骤，主要差别是在客户端发送加密方式之前，服务端会多一步索要客户端证书的步骤，然后在选择好加密方式之后不是通过明文的方式而是通过客户端给的公钥进行加密再进行返回。而其他步骤基本照旧，最终改动如下：
- 客户端发送自己支持的加密方案，提供服务器选择。在此之前插入两个步骤 =>
- 服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端。
- 验证客户端证书，通过认证获得客户端公钥。
- 服务器选好加密方案通过明文方式发给客户端之后添加 => 加密方式通过之前获取的公钥进行加密（不使用明文），返回给客户端。
6.3 表单认证
表单认证也就是我们常说的账号密码登录。绝大多数的网站基本使用表单认证+SSL认证结合的方式，基本能保证99%的请求能建立安全链接，保证客户的信息不被窃取。但是因为表单认证没有规范和标准，质量也参差不齐，所以不是所有网站有表单认证就是安全的，但是有比没用强不少。
6.4 Cookie和Session管理
Cookie 和 Session 作为HTTP无状态的一种用户信息暂存的补救机制，作用是让客户在登录某个网站之后可以保持一段时间或者很长一段时间不需要重新登录，或者说保存一些网站的账户密码登录的时候自动填充，总之是提升浏览器使用体验的东西。
Cookie 和 Session 通常是一起作用的，下面是客户登录中 Cookie 和 Session 作用的基本流程：
- 客户端通过表单发送信息服务器进行表单认证。
- 服务器认证发送SessionID，把用户认证状态和SessionID绑定。
向客户端返回响应时，会在首部字段 Set-Cookie 内写入 Session ID（如 PHPSESSID=028a8c…）。
- 客户端接受SessionId作为Cookie保存本地，下次再次请求会带入Cookie并且随着SessionId一起发送，服务端基于SessionId识别用户和认证状态。
SessionID应该保证其安全性和难以推测的特性，常见处理方式使用加盐对于密码进行二次的哈希处理，这种方式是使用比较多的方式，防止XSS攻击获取到密文之后解密获得账户密码。
为减轻跨站脚本攻击（XSS）造成的损失，建议事先在 Cookie 内加上 httponly 属性。6.5 BASIC 认证和DIGEST 认证
6.5.1 BASIC 认证
BASIC 认证（基本认证）是从 HTTP/1.0 就定义的认证方式。还有极少部分网站在使用，作为大概了解即可。
大致步骤如下：
- 需要 BASIC 认证时，服务器会随状态码
401 Authorization Required，返回带WWW-Authenticate首部字段的响应。 - 状态码
401 Authorization Required通知客户端需要BASIC认证。为了通过BASIC认证，需要把ID密码发给客户端，加密方法是串联用户ID和密码用连接符冒号链接，然后Base64加密。 - 服务器接收到包含首部字段 Authorization 请求，然后返回一条Request-URI响应。
可以看到整个过程最大的问题是Base64不加密，一旦获取到传输信息通过字典暴力破解基本两下就可以解开。
为了解决Basic认证问题，后续出现了DIGEST 认证进行升级，HTTP/1.1 起就有了 DIGEST 认证，DIGEST 认证同样使用质询 / 响应的方式。
什么是质询呢？指的是一方发送认证请求之后需要利用服务器返回的质询码生成响应码，最后通过响应码认证。
6.5.2 DIGEST 认证
整个 DIGEST 认证的过程如下：
- 需要认证时，服务器会随状态码
401 Authorization Required，返回带WWW-Authenticate首部字段的响应，同时Authenticate还会传送响应认证需要的临时质询码。 - 接收到 401 状态码的客户端，返回的响应中包含
DIGEST认证必需的首部字段Authorization信息。 - 服务器接收到包含首部字段
Authorization请求，然后返回一条Request-URI响应。
DIGEST和BASIC认证看上去比较像，但是在安全性上比使用明文Base64多了一重认证，所以安全性要高上不少。但是因为认证方式十分不灵活所以使用的范围依然受限。
现如今的主流认证方式使用身份令牌+对称加密的方式，实际上和质询认证的方式类似，只不过整个流程和细节更加完善一点而已。
另外身份令牌一般用于接口对接，对于一般用户通常依然使用表单认证。
6.6 Keberos 认证和NTLM 认证
Kerberos
是一种身份认证协议，被广泛运用在大数据生态中，甚至可以说是大数据身份认证的事实标准。本文将详细说明 Kerberos 原理。
题外话
Kerberos指的是西方神话中的地狱三头犬。在古希腊神话中Kerberos含义：有着一只三头犬守护在地狱之门外,禁止任何人类闯入地狱之中。
6.6.1 Kerberos 的优势
- 密码无需进行网络传输。基于 Ticket 实现身份认证，保障密钥安全性。
- 双向认证。整个认证过程中，不仅需要客户端进行认证，待访问的服务也需要进行身份认证。
- 高性能。一旦Client获取到曾经访问过某个Server的Ticket，该Server就能根据这个Ticket实现对Client的验证，而无须KDC的再次参与。
个人粗略看了一下这个认证，看上去十分复杂并且流程繁琐，这里找了几篇博客作为储备，有需要之后再来学习，推荐阅读顺序是213，其中第二篇整理的比较系统，第一篇虽然比较老但是是英文的加上给了很多图，适合学技术同时顺带提升英语阅读水平：
https://www.roguelynn.com/words/explain-like-im-5-kerberos/
https://blog.csdn.net/sky_jiangcheng/article/details/81070240
https://zhuanlan.zhihu.com/p/266491528
NTLM
NTLM是NT LAN Manager的缩写，NTLM是基于挑战/应答的身份验证协议，是 Windows NT 早期版本中的标准安全协议。
6.7 参考资料
本章的参考资料就是关于Keberos的认证参考博客，推荐阅读顺序 2、1、3：
https://www.roguelynn.com/words/explain-like-im-5-kerberos/
https://blog.csdn.net/sky_jiangcheng/article/details/81070240
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。