session & cookie & token & JWT | 青训营笔记

XQGang
150 阅读5分钟

这是我参与「第三届青训营 -后端场」笔记创作活动的第5篇笔记

HTTP 是无状态（对于事务处理没有记忆能力，每次客户端和服务端会话完成时，服务端不会保存任何会话信息）的，如何识别用户？

cookie 的工作原理：浏览器第一次发送请求到服务器，服务器创建cookie，将cookie发送到浏览器；如果浏览器再次访问服务器，会携带着cookie；服务器根据浏览器发送过来的cookie，区分不同的用户、权限等。

session 的工作原理：

  1. 用户第一次请求服务器时，服务器端会生成一个sessionid
  2. 服务器端将生成的sessionid返回给客户端，通过set-cookie
  3. 客户端收到sessionid会将它保存在cookie中，当客户端再次访问服务端时会带上这个sessionid
  4. 当服务端再次接收到来自客户端的请求时，会先去检查是否存在sessionid，不存在就新建一个sessionid重复1,2的流程，如果存在就去遍历服务端的session文件，找到与这个sessionid相对应的文件，文件中的键值便是sessionid，值为当前用户的一些信息
  5. 此后的请求都会交换这个 Session ID，进行有状态的会话。

cookie vs session：

  • Cookie 是实现 session 的一种机制，通过 HTTP cookie 字段实现
  • 如果浏览器禁用了 Cookie，那么 Cookie 就不能使用，而 Session 不能禁用
  • 安全性： Session 比 Cookie 安全，Session 是存储在服务器端的，Cookie 是存储在客户端的
  • 存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
  • 有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。
  • 存储大小不同： 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。

Token 的工作原理：

img

  1. 客户端使用用户名跟密码请求登录
  2. 服务端收到请求，去验证用户名与密码
  3. 验证成功后，服务端会签发一个 token 并把这个 token 发送给客户端
  4. 客户端收到 token 以后，会把它存储起来，比如放在 cookie 里或者 localStorage 里
  5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 token
  6. 服务端收到请求，然后去验证客户端请求里面带着的 token ，如果验证成功，就向客户端返回请求的数据

session vs token：

  • Session 是一种记录服务器和客户端会话状态的机制，使服务端有状态化，可以记录会话信息。而 Token 是令牌，访问资源接口（API）时所需要的资源凭证。Token 使服务端无状态化，不会存储会话信息。
  • Session 和 Token 并不矛盾，作为身份认证 Token 安全性比 Session 好，因为每一个请求都有签名还能防止监听以及重放攻击，而 Session 就必须依赖链路层来保障通讯安全了。如果你需要实现有状态的会话，仍然可以增加 Session 来在服务器端保存一些状态。
  • 所谓 Session 认证只是简单的把 User 信息存储到 Session 里，因为 SessionID 的不可预测性，暂且认为是安全的。而 Token ，如果指的是 OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对 App 。其目的是让某 App 有权利访问某用户的信息。这里的 Token 是唯一的。不可以转移到其它 App上，也不可以转到其它用户上。Session 只提供一种简单的认证，即只要有此 SessionID ，即认为有此 User 的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方 App。所以简单来说：如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。如果永远只是自己的网站，自己的 App，用什么就无所谓了。

JWT 的工作原理：

  • 用户输入用户名/密码登录，服务端认证成功后，会返回给客户端一个 JWT

  • 客户端将 token 保存到本地（通常使用 localstorage，也可以使用 cookie）

  • 当用户希望访问一个受保护的路由或者资源的时候，需要请求头的 Authorization 字段中使用Bearer 模式添加 JWT，其内容看起来是下面这样

    Authorization: Bearer <token>

  • 服务端的保护路由将会检查请求头 Authorization 中的 JWT 信息，如果合法，则允许用户的行为

  • 因为 JWT 是自包含的（内部包含了一些会话信息），因此减少了需要查询数据库的需要

  • 因为 JWT 并不使用 Cookie 的，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）

  • 因为用户的状态不再存储在服务端的内存中，所以这是一种无状态的认证机制

Token vs JWT：

  • Token：服务端验证客户端发送过来的 Token 时，还需要查询数据库获取用户信息，然后验证 Token 是否有效。

  • JWT： 将 Token 和 Payload 加密后存储于客户端，服务端只需要使用密钥解密进行校验（校验也是 JWT 自己实现的）即可，不需要查询或者减少查询数据库，因为 JWT 自包含了用户信息和加密的数据。

avatar
文章
阅读
粉丝