一文搞懂 Cookie、Session 和 Token 的区别

背景

在 Web 应用中，HTTP 是无状态协议，服务器无法自动识别用户身份。为了实现用户登录状态的保持与身份认证，需要引入 Cookie、Session 和 Token 等机制来在多次请求之间维持用户状态

Cookie

Cookie 是存储在客户端（浏览器）的一小段数据，会在每次请求时自动携带到服务器。特点有如下：

• 自动发送
• 容量小（4KB）
• 可以被 JS 读取（除非 HttpOnly）

Cookie 的结构长什么样子

一个典型的 Cookie：

Set-Cookie:sessionId=abc123;Path=/;Domain=example.com;HttpOnly;Secure;SameSite=Strict

• 存储的核心数据是用键值对的形式name = value， 比如sessionId = abc123。
• 其次，Domain（作用域）， Domain=example.com， 哪些域名可以使用这个 Cookie。.example.com 👉 子域名也能用，a.example.com 👉 仅该子域。
• Path=/， 表示哪些路径能够携带这些cookie
• Expires / Max-Age（过期时间）
• HttpOnly（安全）设置这个，JS 不能访问,document.cookie ❌（读不到），能够防止 XSS 偷 Cookie
• Secure（安全），只在HTTPS下发送
• SameSite, 防止CSRF

Cookie的工作流程

1. 第一次请求
   浏览器 -> 服务器发送get/post请求
   服务器返回 Set-Cookie: sessionId=abc123
2. 后续请求
   浏览器自动带上： Cookie: sessionId=abc123

Cookie的常见用途

cookie可以用来存储如下：

• 登录状态（sessionId）
• 用户偏好（语言/主题）
• 购物车
• 追踪用户行为（埋点/广告）

Cookie 存在的问题

• Cookie 存在以下几个主要问题：首先是容量和数量限制，单个 Cookie 大约 4KB，且每个域名数量有限；
• 其次是作用域受 Domain 和 Path 限制，无法跨域使用；
• 第三是浏览器会自动携带 Cookie，容易导致 CSRF 攻击；
• 另外 Cookie 存储在客户端，存在被篡改的风险，同时如果未设置 HttpOnly，可能被 XSS 攻击窃取；
• 最后在非 HTTPS 场景下，Cookie 还可能被窃听。因此在实际开发中需要结合 HttpOnly、Secure、SameSite 等属性来增强安全性。

Cookie总结

Cookie 是由服务器设置并存储在客户端（浏览器）的一小段键值对数据，会在后续请求中自动携带到服务器。它常用于维持会话状态，例如存储 sessionId。Cookie 具有 Domain、Path、Expires、HttpOnly、Secure 和 SameSite 等属性，用于控制作用范围和安全性。
Cookie 的主要问题包括容量和数量限制、受同域策略限制、浏览器自动发送容易导致 CSRF 攻击，以及可能被 XSS 窃取或被用户篡改。因此在实际开发中通常会结合 HttpOnly、Secure 和 SameSite 等属性来提升安全性。

Session

Session 是服务器用来记录用户状态的数据，服务器用来记录用户状态的数据，通过 Cookie 中的 sessionId 来识别用户。

Session 里面通常存储什么

1. 首先就是用户身份信息

{"userId":1001,"username":"zhangsan"}

2. 登录状态

{"isLogin":true}

3. 权限信息

{"role":"admin","permissions":["read","write"]}

Session存储在哪里

1. 内存，直接存储在服务器的内存中，但是这样重启就消失了
2. 数据库，Mysql等，这样能够持久化但是相对性能会差一些
3. Redis(最常用), 高性能支持过期时间，分布式支持

Session流程

🧭 登录时
用户登录, 服务器创建 Session：

{"sessionId":"abc123","userId":1001}

返回 Cookie：Set-Cookie: sessionId=abc123
🔁 后续请求
浏览器带 Cookie：

Cookie:sessionId=abc123

服务器查 Session
获取用户信息 ✔

Session 存在的问题

1. 占用服务器资源
   每个用户都需要存储
2. 不利于分布式
   在多台服务器的时候

用户请求 → 服务器A（有Session） 下一次 → 服务器B（没有Session） ❌

3. 依赖cookie
   仍然有CSRF的风险

Session总结

Session 是服务器端用于存储用户状态的数据结构，通常以键值对形式存在，通过 Cookie 中的 sessionId 来进行关联。Session 中一般会存储用户身份信息、登录状态、权限信息以及一些临时业务数据。为了提高性能和支持分布式系统，Session 通常会存储在内存或 Redis 中。

Token

Token 是一种用于身份认证的凭证，由服务器生成并返回给客户端，客户端在后续请求中携带该凭证来证明自己的身份。

Token的工作流程

🧭 登录阶段
用户登录
服务器验证账号密码 ✔
生成 Token（例如 JWT）
返回给客户端

🔁 后续请求

客户端每次请求带上：

Authorization: Bearer token
👉 服务器验证 Token ✔
👉 通过 → 返回数据

JWT(最常见的token)

Json web token是目前最常见的方式
Jwt由三部分组成

Header.Payload.Signature

1. Header
   头部用来描述加密算法

{"alg":"HS256","typ":"JWT"}

2. Payload
   存用户信息

{"userId":1001,"username":"zhangsan","exp":1710000000}

3. Signature
   用密钥生成：防止被篡改

HMACSHA256(base64(header)+"."+base64(payload),secret)

Token的特点

优点：
❌ 无需服务器存储（无状态）
✔ 支持分布式（天然适合微服务）
✔ 跨域友好（前后端分离必备）
✔ 性能好（不用查数据库）

缺点：
❗一旦泄露 → 无法立即失效
❗Payload 可被解码（不能放敏感信息）
❗需要手动管理（不像 Cookie 自动发送）

Token的安全问题

1. XSS → 偷 Token

如果存：

localStorage ❌

👉 JS 可以拿到

2. Token 泄露

👉 被截获就能用

防御措施

• 使用 HTTPS ✔
• 设置过期时间（exp）✔
• 使用 Refresh Token ✔
• 不在 Payload 放敏感信息 ✔

Token总结

Token 是一种用于身份认证的凭证，通常由服务器生成并返回给客户端，客户端在后续请求中通过 Authorization 头携带 Token 来完成身份验证。常见实现是 JWT，它由 Header、Payload 和 Signature 三部分组成。相比 Session，Token 具有无状态、易扩展的特点，适用于前后端分离和分布式系统，但需要注意 Token 泄露和过期管理等安全问题。