Cookie、Session、JWT
目录
实现方式与原理
存储位置
安全性
应用场景
Cookie、Session 和 JWT（JSON Web Token）都是 Web 开发中用于用户身份验证和会话管理的技术，它们在实现方式、存储位置、安全性等方面存在差异：
实现方式与原理
- Cookie：是服务器发送到客户端（浏览器）并存储的小型文本文件。用户首次访问网站并登录时，服务器生成包含用户标识等信息的 Cookie，通过 HTTP 响应头中的
Set - Cookie指令发给浏览器。浏览器存储该 Cookie，后续用户再次访问同一网站时，浏览器会在 HTTP 请求头中自动携带该 Cookie，服务器据此识别用户身份 。例如，用户登录某论坛后，论坛服务器会给浏览器发送 Cookie，下次用户再访问论坛，浏览器带着 Cookie，服务器就能认出是该用户。 - Session：是服务器端用于存储用户会话信息的机制。用户登录时，服务器创建 Session 并生成唯一的 Session ID，同时将用户相关会话信息（如用户 ID、登录时间等）存储在服务器内存或数据库中。服务器通过
Set - Cookie响应头把 Session ID 发送给浏览器存储。后续请求中，浏览器携带 Session ID，服务器根据此 ID 查找对应的 Session 数据来识别用户、验证身份。比如在电商网站购物，登录后服务器创建 Session 记录购物车等信息，通过 Session ID 识别用户操作。 - JWT：是一种开放标准（RFC 7519），以 JSON 对象形式在客户端和服务端安全传输信息。它由头部（包含令牌类型和签名算法等信息）、载荷（包含声明信息，如用户身份、权限、有效期等）、签名（用于验证信息完整性和真实性，通过对头部、载荷等使用密钥和指定算法生成）三部分构成。用户登录成功，服务器生成 JWT 并发送给客户端。客户端后续请求时，将 JWT 放在请求头的
Authorization字段（常用Bearer <token>形式 ）等位置发送给服务器，服务器验证 JWT 的签名等信息来确认用户身份和权限。像前后端分离的项目中，前端登录后获取 JWT，后续向后端接口请求数据时带上 JWT。
存储位置
- Cookie：存储在客户端浏览器。
- Session：会话数据存储在服务器端，而用于标识会话的 Session ID 存储在客户端浏览器的 Cookie 中。
- JWT：存储在客户端，常见存储位置有浏览器的
localStorage、sessionStorage，或者在 HTTP 请求头的Authorization字段等 。
安全性
- Cookie：安全性相对较低，易被窃取、篡改。虽可通过设置
HttpOnly（防止 JavaScript 读取 Cookie，降低跨站脚本攻击风险）、Secure（仅在 HTTPS 连接时传输 Cookie ）等属性增强安全，但仍存在跨站请求伪造（CSRF）风险 。例如，攻击者利用用户已登录状态的 Cookie，在其他网站诱导用户发起恶意请求。 - Session：会话数据在服务器端，相对安全。但如果 Session ID 泄露，攻击者可能利用该 ID 冒充用户，存在会话固定攻击等风险 。
- JWT：通过签名机制保证数据完整性和真实性，可结合加密技术提升安全性，一定程度上抵御跨站脚本攻击等。但由于 JWT 的载荷是用 Base64 编码（并非加密），不宜在其中存储敏感信息；若密钥泄露，JWT 安全性将受严重威胁。
应用场景
- Cookie：适用于存储用户偏好（如语言设置、主题偏好）、记录用户浏览历史等简单场景；也常用于传统 Web 应用的会话管理，配合 Session 使用实现用户登录状态保持等 。
- Session：适合传统 Web 应用，尤其是有服务器端渲染、对会话状态管理要求较高的场景，如银行系统的用户登录会话管理，可在服务器端灵活控制会话有效期、存储用户操作记录等敏感信息 。
- JWT：在分布式系统、前后端分离架构、移动应用、微服务架构中广泛应用。比如多个微服务组成的系统中，JWT 便于在不同服务间传递用户身份信息，实现统一认证和授权 。