概述

我们使用计算机购物、通信最终要的部分莫过于验证用户的身份，这也是互联网+系列的基础。

为了保证服务器唯一认证用户，我们需要保证两点：

1. 用户拥有唯一的凭证，这个凭证跟其他用户不一样，而且是隐秘的；
2. 服务器和客户端是通过互联网连接的，通信线路上的某些网络设备、光缆、计算机等都不可能是个人私有的，所以不排除某个环节会遭到恶意窥视行为，所以我们还必须加密通信信息，防止中间人攻击。

1. BASIC认证

BASIC认证（基本认证）是从HTTP/1.0就定义的认证方式。现在基本不使用了。

当访问的资源需要认证的时候，服务器会返回401（Authorization Required），浏览器会弹框收集用户的账号密码，并把它们进行Base64处理。

这种方式在不依赖SSL的情况下是很不靠谱的，很容易被中间人截获你的账号密码。

2. DIGEST认证

为了弥补BASIC认证存在的弱点，从HTTP/1.1起就有了DIGEST认证。DIGEST认证不会直接发送密文密码（包括Base64编码后的）。

基本过程是服务器生成一串随机数传送给客户端，让客户端使用用户的密码来处理这串随机数，然后返回给服务器认证，这样就可以保证用户的密码不外泄了。

DIGEST认证提供防止密码被窃听的保护机制，但并不存在防止用户伪装的保护机制（中间人攻击）。所以后来也基本不使用了。

3. SSL客户端认证

SSL后来发展成TLS，是HTTPS的核心。

表单认证

表单认证是由服务器主导的认证方式。

以前表单认证一般是使用账号密码来认证；
再后来有了邮箱、手机号码认证；
再后来有OAuth授权方式——包括跳转到认证中心、扫码登录。

单点登录

为了优化用户体验，减少登录次数，一般拥有很多子应用（网站）的企业会提供单点登录系统，使用户只要在其中一个子应用（网站）里登录后，可以在一段时间内免登陆其它的子应用（网站）。

思路大致是：

所有子应用（网站）都需要引导用户跳转到授权中心，登录成功后授权中心会保留一份全局会话（session）并保留sessionID到cookie，然后引导用户返回子应用并带上一份token，子应用会使用这个token去和授权中心兑换用户信息并保留为局部会话（session）。

当用户短时间内打开第二个子应用（网站），还是会被引导到授权中心，但是因为cookie上的sessionID没有过期，所以可以免去登录，授权中心会像第一次一样引导用户返回第二个子应用（网站）。

这里有一个技术难点需要提一下，就是如果用户主动注销了状态，还需要子应用调用接口把授权中心的sessionID清理掉。

参考

《图解HTTP》