用户认证：让服务器知道你是谁？
授权：让服务器告诉你能做什么？不能做什么？

为了解决 Basic access authentication 每次请求敏感资源都要带有用户名密码凭证的问题，
web开发者们形成了一套基本的实践模式，就是将用户认证后的身份存储于服务端管理的会话（session）之中，以此来减少使用过程中对凭据的传输
https://www.jianshu.com/p/2b7c10291aad
https://bugszhou.abuen.com/cookie/session/principle.html

session 验证原理

  1. 用户想要请求受保护资源，先要登录，向服务端发送用户名密码。
  2. 服务端验证用户名密码成功之后将用户的身份验证标识存储在session 中，然后将sessionId存储在cookie 中。
  3. 之后当客户再去请求受保护资源的时候，只要携带 cookie中的 sessionId就可以验证其身份返回敏感数据

image.png
image.png

session验证缺点

基于session的认证模式犹豫其简单、方便、好用，所以被广泛使用
随着web应用的发展，其也出现了诸多不足：

  1. 当服务器应用重启时，用户会被强制登出
  2. 当站点用负载均衡部署多份时，或分布式部署时，每个站点实例的session无法共享

当然，我们可以使用单独的session存储服务来解决这些问题，但这样会增加系统不小的复杂性与维护成本。

session

  1. session主要放在服务器端，相对安全
  2. cookie主要存放在客户端，相对不安全
  3. sessionStorage 仅在当前会话下有效，关闭页面或浏览器后会被清除
  4. localStorage 如果不手动清除，会一直保存，除非卸载浏览器

session的优势

  1. 相对 jwt，服务端可以主动的清除 session
  2. session保存在服务端，先对安全
  3. 结合 cookie使用，较为灵活，兼容性好

session的缺点

  1. cookie + session在跨域场景下表现不好
  2. 如果是分布式部署，需要做多机共享 session机制
  3. 基于 cookie的机制，很容易被 CSRF攻击，跨站请求伪造
  4. 查询 session信息可能有数据库查询操作