1. http basic认证
HttpBasic认证是Http自带的认证方式，这种认证方式通常表现为浏览器弹出Alert窗口提示输入用户名/密码。
其交互过程如下：
- 开始时，客户端发送未携带身份信息的请求。
- 服务端返回 401 Unauthorized 状态，并在返回头中说明要用
Basic方法进行认证：WWW-Authenticate: Basic。 - 客户端重新发送请求，并将身份信息包含在请求头中:
Authorization: Basic aHk6bXlwYXNzd29yZA==。 - 服务端验证请求头中的身份信息，并相应返回 200 OK 或 403 Forbidden 状态。
- 之后，客户端每次发送请求都在请求头中携带该身份信息。
其中传送的身份信息是 <username>:<password> 经 base64 编码后的字串。如本例中的 aHk6bXlwYXNzd29yZA==， 经 base64 解码后为 hy:mypassword。
这种认证方法的优点是简单，容易理解。
缺点有：
- 不安全：认证身份信息用明文传送，因此需结合 https 使用。
- 效率低：服务端处理请求时，每次都需要验证身份信息，如用户名和密码。
1.1 http digest认证
HttpBasic认证很少在可公开访问的互联网网站上使用，有时候会在小的私有系统中使用（如路由器网页管理接口）。
digest认证是另一种HTTP认证协议，它试图修复基本认证协议的严重缺陷。具体来说，摘要认证进行了如下改进：永远不会以明文方式在网络上发送密码；可以防止恶意用户捕获并重放认证的握手过程；可以有选择地防止对报文内容的篡改；防范其他几种常见的攻击方式
需要注意的是，digest认证除了能够保护密码之外，并不能保护其他内容。使用传输层安全(Transport Layer Security, TLS)和安全HTTP(HTTPS)协议更为合适一些。所以迄今为止，摘要认证还没有被广泛应用。
2. session认证
这种认证方法结合了 Session 和 Cookie。服务端将本次会话信息以 Session 对象的形式保存在服务端的内存、数据库或文件系统中，并将对应的 Session 对象 ID 值 SessionID 以 Cookie 形式返回给客户端，SessionID 保存在客户端的 Cookie 中。
这是有状态的认证方法：服务端保存 Session 对象，客户端以 Cookie 形式保存 SessionID。
其交互过程如下：
- 客户端在登录页面输入身份信息，如用户名/密码。
- 服务端验证身份信息，通过后生成一个 Session 对象，保存到服务端，并将 SessionID 值以 Cookie 形式返回给客户端。
- 客户端将接收到的 SessionID 保存到 Cookie 中，并且之后每次请求都在请求头中携带 SessionID Cookie。
- 服务端从请求的 Cookie 中获取 SessionID，并查询其对应的 Session 对象，从而获得身份信息。
- 客户端退出本次会话后，客户端删除 SessionID 的 Cookie，服务端删除 Session 对象。
- 如果客户端之后要重新登录，需重新生成 Session 对象和 SessionID。
优点：
- 较安全：客户端每次请求时无需发送身份信息，只需发送 SessionID。
- 较高效：服务端无需每次处理请求时都要验证身份信息，只需通过 SessionID 查询 Session 对象。
缺点：
- 扩展性差，Session 对象保存在服务端，如果是保存在多个服务器上，有一致性问题，如果保存在单个服务器上，无法适应用户增长。
- 基于 Cookie 的 SessionID 不能跨域共享，同一用户的多个客户端（如浏览器客户端和 APP）不能共享 SessionId。
- 基于 Cookie 的 SessionID 易被截获生成 CSRF 攻击。
3. token 认证
这是一种 SPA 应用和 APP 经常使用的认证方法。它是一种无状态的认证方法。
客户端首先将用户信息发送给服务端，服务端根据用户信息+私钥生成一个唯一的 Token 并返回给客户端。Token 只保存在客户端，之后客户端的每个请求头中都携带 Token，而服务端只通过运算（无需查询）来验证用户。
优点：
- Token 只保存在客户端，因此不影响服务端扩展性。
- 为用户生成的 Token 可以在多个客户端共用。
缺点：
- Token 包含了用户的全部信息，不只是如 SessionID 类似的一个 ID 值，因此会增加每次请求包的大小。
目前使用较多的是基于JWT(JSON Web Tokens) 的 Token 认证法。
