1. 基于 Session 的认证
长期以来，基于 Session 的认证（Session Based Authentication）一直处于主流地位。由于 HTTP 是无状态的，借助 Cookie，客户端登陆成功后，服务端能识别出其后续请求，无需每次都登陆。它是有状态的（stateful），即服务端和客户端都需要保存生成的 Session。基本过程如下：
- 客户端用自己的凭证（比如用户名和密码）进行登陆（Login）
- 如果服务端验证通过，那么生成 Session，并把它存入 Session Storage（比如运行时内存、文件、Redis 等）
- 服务端通过 Set-Cookie，将 Session Key 写到客户端浏览器的 Cookie 中
- 客户端的后续请求都会自动携带 Cookie
- 如果客户端登出（Logout），那么服务端和客户端销毁 Session
1.1. 缺点
服务端需要为每个用户保存 Session，对于拥有大量用户的场景，服务端的负担很重。另外一方面，不能很好地解决跨域资源共享（Cross-Origin Resource Sharing）。最重要的是使用 Cookie 引入很多不安全因素，比如 CSRF 攻击。
2. 基于 Token 的认证
近年来，基于 Token 的认证（Token Based Authentication）成为主流。该认证方式是无状态的（stateless），客户端登陆成功后，服务端生成 Token 并把它返回给客户端，服务端不保存该 Token。
服务端颁发的 Token 是用自己的密钥签名的，当它收到客户端的 Token 时，只需要自己的密钥就可以验证 Token 是否合法。基本过程如下：
- 客户端用自己的凭证登陆
- 如果服务端验证通过，那么生成 Token（比如使用 HMAC、RSA 算法生成），并返回给客户端
- 客户端存储 Token（比如写到浏览器的 Local Storage），后续请求都携带该 Token
- 服务端收到请求时，验证 Token，如果验证通过，那么允许用户访问相应的资源
2.1. 缺点
如果 Token 被窃取，那么就会带来危险。因此服务端需要给 Token 设置合理的过期时间（expired time），当用户登出时，服务端需要把当前 Token 加到黑名单，防止被冒用。
2.2. 优点
无状态（stateless）
服务端无需保存 Token，Token 中含有验证需要的所有信息，比如签名算法、签名等
在 JWT 中存储数据
不需要 CSRF（Cross Site Request Forgery） 防护