cookie、session、token 区别

title: cookie、session、token 区别
search: 2024-03-20
tags:

• “#cookie、session、token 区别”

cookie、session、token 区别

Tips ：他们本质上是不同的，但是都跟维持状态信息有关

一、三者在登录业务上的区别

维持状态信息：当我们登录之后，如果我们希望后续所有的页面都维持登录的状态，我们一般会使用cookie,session,token 来实现， 如果我们都不使用，那么维持用户的登录信息是十分麻烦的，以下举例说明

思考

1. 不用 cookie,session,token 技术

1.1 认证流程

Step-1：用户端发起登录请求，发账号密码给服务端

Step-2：服务端进行鉴权认证，判断用户名密码是否正确合法

1. 认证成功 服务端将用户名和用户密码再次发送给前端，前端用以维持用登录

2. 认证失败 发送用户鉴权失败信息给前端

Step-3：后续请求的任何页面，我们都需要带上用户名和密码，反复进行鉴权认证

Tips：毫无疑问，这样既麻烦又不安全，你可能会问，为什么我每次请求任何页面，都需要带上用户名和密码呢，都需要重新鉴权呢？

​

因为服务器没有存储你的登录信息，上一次请求和这一次请求完全是分割开来的，在这一次请求中，服务器怎么知道你已经登录了？

既然没有信息存储证明你已经登录，那么只能够不断反复验证权限，以保证用户信息的安全性。

2. cookie 解决方案

2.1 cookie 认证流程

思考：既然没有存储用户的登录信息，那么储存了用户登录信息是不是可以解决问题？

cookie 存储在哪一端：cookie 存储在客户端中的浏览器中

Step-1：用户端发起登录请求，发账号密码给服务端

Step-2：服务端进行鉴权认证，判断用户名密码是否正确合法

1. 认证成功 服务端将 用户名 响应发送给前端 （response:set-cookie）
   1. 前端把 用户名 保存到 cookie
   2. 后续前端发的所有请求，在请求头中都会自动带上 cookie
2. 认证失败 发送用户鉴权失败信息给前端

提问：只用cookie 来存储状态信息，可能会有什么问题？

2.2 Cookie 问题

• 安全风险：有被客户篡改的可能
  • 用户可以直接篡改客户端的 cookie 伪装身份成为其他人
  • 服务端只会根据 cookie 中的 用户名，获取当前登录信息
  • 可以对 Cookie 数据进行加密，保证加密规则不外泄即可
• 容量限制：4kb （默认大小，可以通过浏览器进行修改）
• 可用限制：用户可能禁用 （用户可以在浏览器端选择禁用 Cookie）

Tips：以上 cookie存储用户名只是用于举例 ，并非表示cookie 中只能有 用户名，实际上 cookie 里面能存入很多东西的

2.3 Google浏览器cookie 查看

Step-1：打开 google 浏览器，按下 F12 打开 开发者工具，或者找到右上角的三个竖着的点，在 更多工具 --> 开发者工具 里

Step-2：切换到 Application 界面

Step-3：找到 Cookies 下面是你目前存储在浏览器中所有网站的 Cookie ，我这里就点开了百度的 Cookie 可以看到里面有很多Name 和 Value，这些Value 都是可以修改的

2.4 总结

我们不能完全依赖于 Cookie 进行登录状态的维持

以下是 cookie 应用场景

1. 用户登录状态维持：
   • 当用户登录网站后，服务器可以通过设置一个包含认证信息的cookie，使得用户在后续访问同一网站时不需要重新输入用户名和密码，从而实现“记住我”的功能。
2. 个性化体验：
   • 存储用户的偏好设置，例如字体大小、界面布局、主题风格等，以提供个性化的页面展示。
3. 会话追踪：
   • 记录用户的访问轨迹，用于分析用户行为、兴趣偏好或地理位置等，以便提供更符合用户需求的服务或内容推荐。
4. 购物车功能：
   • 在电子商务网站中，轻量级的购物车信息有时会被存储在cookie中，以便用户在不同页面间切换时仍能看到已添加的商品。
5. 广告追踪与分析：
   • 第三方广告服务提供商可能会使用cookie来追踪用户的浏览历史，以便推送定向广告或者进行网站流量分析。
6. 安全性限制：
   • 有时候cookie被用于实施安全措施，例如CSRF（跨站请求伪造）令牌，确保请求确实来自于已经授权的用户。
7. 网站统计与分析：
   • Google Analytics等网站分析工具使用cookie来跟踪用户访问次数、新老访客识别等指标。
8. 分布式应用共享状态：
   • 在大型网站或分布式系统中，cookie可以帮助不同的服务器节点识别同一个用户，从而提供连续一致的服务。

3. session 解决方案

3.1 认证流程

思考：既然存储用户的登录信息存在于客户端会导致安全问题，那么储存在服务端是不是可以解决问题？

session 存储在哪一端：session 一般 存储在服务端

Step-1：用户端发起登录请求，发账号密码给服务端

Step-2：服务端进行鉴权认证，判断用户名密码是否正确合法

1. 认证成功 服务端往 session 中存入当前用户信息 ，并响应前端请求（response-header:set-cookie(sessionid)）
   1. 后端响应前端时会带上 set-cookie 属性，同时将当前 session 的唯一ID，放入属性中
   2. 前端拿到 session ID 后会自动存入到 cookie 中
   3. 后续前端每次请求，都会在 request header 的 cookie 中带上唯一的 session ID
   4. 后端拿到唯一的 session ID 就可映射当前 session ID 对应的用户信息，以维持用户登录状态
2. 认证失败 发送用户鉴权失败信息给前端

3.2 Session 优劣

优势

• 后端只要往 Session 里面存入用户信息，不仅限于字符串，对象也可以（容量大）
• 获取 Session 信息方便，Session ID 唯一映射
• Web 服务器端（如tomcat），会在响应头存入 set-cookie 属性，以及当前 session 唯一ID
• 浏览器检测有响应有set-cookie 属性，会自动存入 cookie 中，前端不需要手动去调用 setCookie() 方法
• 下一次前端请求会自动带上 cookie 发送给后端
• 存储在服务器端，安全性大大提高，避免篡改风险

劣势

• 占用服务器资源
• 扩展性差 （分布式集群）
• 需要依赖 cookie
• 跨域限制
• 小程序不支持 cookie

扩展性差：

1. 当后端压力大时，我们可能对后端进行集群部署，如 192.168.1.101:8001，192.168.1.102:8002，192.168.1.103:8003
2. 此时前端发起登录请求，我们往 session 存入当前 A用户 信息，只会在一台服务器中存储，如 192.168.1.101:8001
3. 其他服务器是没有 A用户 的登录信息的
4. 集群之后的 负载均衡 可能下一次请求就会打到其他服务器上
5. 判定用户没有登录

其实扩展性差的问题，放在集群部署中，要考虑的无非就是 session 共享问题

跨域问题：对跨域问题没有了解的，可以参考如下视频 你可以轻松搞定跨域问题吗？先从浏览器的同源策略入手，跟住我！

1. 在当下移动端盛行情况下，我们可能有 网页端 192.168.1.102:8080，移动端 192.168.1.102:8090，小程序端，Android端，Mac端等等 192.168.1.102:XXXX
2. 这些端都会有各自端口和域名，这个时候前端再次请求后端，就会发生跨域问题
3. 跨域情况下 cookie 默认是无法进行传递的
4. 解决思路是 后端设置允许跨域，前端单独设置允许跨越的 cookie 传递 （跨域传递cookie 十分麻烦）

3.3 总结

如果是高并发使用场景不推荐使用，消耗服务器资源，其余场景安全性较高。

以下是 session 应用场景

1. 用户登录状态管理：
   • 当用户成功登录后，可以在服务器端的session中存储用户的身份标识（如用户ID）、登录状态和其他相关权限信息。每次用户发起新的请求时，服务器根据请求中携带的session ID确认用户的身份和登录状态。
2. 会话管理：
   • Session可以用来跟踪用户在整个会话期间的行为，比如记录用户的浏览历史、操作记录等。一旦会话结束（如浏览器关闭或超时），这些信息会随着session的销毁而清除。
3. 购物车功能：
   • 用户在电商网站中选择的商品信息可以暂时存放在session中，这样无论用户在哪一页浏览或操作，只要会话还在继续，商品信息都能保持一致，直到用户结算或清空购物车。
4. 个性化设置：
   • 保存用户的个性化配置，如页面布局、主题颜色、语言选项等临时设置，可以在整个会话过程中持续影响用户体验。
5. 权限验证与访问控制：
   • 对于需要权限验证才能访问的功能或页面，服务器利用session中的用户角色或权限信息来决定是否允许访问。
6. 防止重复提交：
   • 在一些防止表单重复提交的场景下，可以在session中设置一次性令牌或标记，确保用户的一个动作只被执行一次。
7. 自动登录功能：
   • 通过将session ID持久化到cookie（例如记住我/Keep Me Logged In功能），允许用户在一段时间内无需重新登录即可访问受保护的内容。

4. token 解决方案

思考：为了在前后端分离的架构下，以及集群环境下适用，用什么方法能够解决 session 的问题呢？

token 本身就是一个密钥字符串，既然是 密钥 字符串，自然延伸的问题是，怎么对它进行加密，以及加密的规范是什么？

JWT 就是为了解决这个问题的，可参考下文 (JWT基本原理）

4.1 认证流程

Step-1：用户端发起登录请求，发账号密码给服务端

Step-2：服务端进行鉴权认证，判断用户名密码是否正确合法

1. 认证成功 服务端将创建一个 JWT 字符串响应发送给前端 （response:{token:xxx.xxx.xxx}）
   1. 前端拿到 JWT 的 token，如果想要数据，就分割第二段 xxx ，第二段是数据的载体，拿到后进行 Base64 解码就可以了
   2. 后续前端发的所有请求，在请求头中都会自动带上 {Authorization:token}，把 token 传送给后端
   3. 后端拿到 token 后会进行 token 解密，检查 signature 进行放行，如果 signature 没有被修改，就会进行放行
2. 认证失败 发送用户鉴权失败信息给前端

4.2 token 优劣

优势

• 无状态性，token 本身包含了所有必要的用户信息或授权信息，服务器无需存储关于用户会话的状态信息，降低了服务器内存压力。
• 跨域支持，由于token可以轻松附加在HTTP请求头中（如Authorization头），不受同源策略限制，因此非常适合跨域应用场景。
• 通过将token作为请求的一部分，而不是依赖于cookie，可以在一定程度上降低 CSRF（跨站请求伪造）攻击的风险.
• 安全性高，使用非对称加密算法颁发的token 可以保证即使在网络上传输也不会泄漏敏感信息，只有拥有私钥的服务端才能解密并验证token的有效性。
• 灵活性高，token可以自由定制，包含自定义的有效载荷信息，并且可以指定过期时间，便于实现细粒度的权限控制。

劣势

• 安全性风险，如果token没有正确实现安全措施，例如未加密存储或传输过程未受到保护，那么token被盗用可能导致安全问题。
• 因为token是无状态的，如果用户注销或权限发生变化，如果不实时更新或撤销token，服务器无法立即终止旧token的有效性，只能等待token过期。
• 存储与刷新频繁，token的存储需要妥善管理，如若存放在客户端且未加密，易遭窃取；同时，长生命周期的token需要刷新机制来延长用户会话，否则可能导致用户频繁重新登录。

4.3 总结

token 非常适合集群式系统，是现代鉴权的主流方式

以下是 token 应用场景

1. 身份验证与授权：
   • 用户登录验证：用户首次登录后，服务器会生成一个token并发送给客户端（如浏览器、移动应用等）。后续客户端发起的所有请求都携带此token，服务器通过验证token有效性确认用户身份，从而实现免密登录或单点登录。
   • 授权：token中可以包含用户的权限信息，服务器根据token的权限标识符判断用户是否有权访问某些资源或执行特定操作。
2. API访问控制：
   • 在微服务架构和RESTful API设计中，Token经常被用作API调用的凭证，确保只有经过认证的客户端才能调用受保护的API。
3. Web应用与移动应用：
   • 不仅限于Web浏览器，Token同样适用于移动应用的身份验证，通过在每次请求中附带Token，实现用户登录状态的保持。
4. 区块链与加密货币：
   • 在区块链技术中，Token代表数字货币（如比特币、以太币等）或者代表其他类型的资产（ERC-20、ERC-721等标准Token）。
5. 去中心化应用（DApps）与DeFi：
   • 在去中心化应用中，Token用于用户之间的交易、治理投票以及智能合约的执行等。
6. 游戏与虚拟世界：
   • 游戏中，Token可以用作虚拟货币、积分系统或兑换凭证，玩家通过Token购买装备、道具或参与游戏内的经济活动。

参考文献

1. Jwt详解，session，token
2. 基于session 和 token的身份认证方案
3. 你真的了解JWT？这篇刷新你的认识！
4. 你可以轻松搞定跨域问题吗？先从浏览器的同源策略入手，跟住我！
5. 10分钟助你弄懂cookie、session、token区别、用途