认证鉴权技术解析：COOKIE | SESSION | TOKEN | JWT | SSO

认证鉴权中会反复提到COOKIE、SESSION、TOKEN、JWT、SSO，你能说出他们之间的区别与联系么？接下来跟随博主的视角一一理清。

一、HTTP 无状态性与基础解决方案：Cookie

HTTP 协议天然无状态，每次请求独立，无法自动关联用户身份。Cookie 作为最早的解决方案应运而生。

• 原理：服务端通过响应头 Set-Cookie 向客户端（浏览器）写入键值对数据，后续请求时浏览器会自动携带该数据。
• 特性：
  • 可配置域名（Domain）、路径（Path）限定作用范围；
  • 通过 Expires/Max-Age 控制生命周期；
  • 安全属性 Secure（仅HTTPS传输）、HttpOnly（禁止JS访问，防止XSS攻击）提升安全性。
• 局限：
  • 容量限制：Chrome限制每个域名下的总Cookie大小为几MB，每个Cookie最大为4KB；

    如果需要存储大量数据，可以考虑使用其他浏览器存储方式，例如localStorage或sessionStorage；

  • 跨域限制：为了保护用户的隐私和安全，防止恶意网站获取其他网站的Cookie，默认情况下Cookie是禁止跨域的。但在某些特定场景下，可以通过一些技术手段实现跨域Cookie共享，例如通过设置 domain 和 path 属性以及使用CORS（跨域资源共享）；
  • XSS攻击：未设置 HttpOnly 时可能被XSS攻击窃取。

示例：用户登录后，服务端返回 Set-Cookie: session_id=abc123，后续请求自动携带此ID标识用户身份。

若对浏览器的安全机制（同源策略SOP和跨域资源共享CORS）感兴趣，可以参阅往期博文：

• 同源策略SOP详解：没有SOP就没有隐私
• 跨域资源共享CORS漏洞详解

二、服务端状态管理：Session

为解决Cookie存储敏感数据的安全风险，Session 方案将用户状态移至服务端：

• 原理：
  1. 用户登录后，服务器创建Session并存储用户信息（如内存/Redis/数据库），同时返回Session ID至客户端Cookie；
  2. 后续请求携带 SessionID 后，服务端查询对应数据。
• 优势：
  • 避免客户端直接存储敏感信息；
  • 服务端可主动销毁Session（如用户登出）。
• 缺点：
  • 扩展性差：集群部署时需Session共享（如Redis），增加服务器负担。
  • 性能瓶颈：高并发时占用大量内存。
  • CSRF漏洞：依赖Cookie易被伪造。

若想了解Session的工作机制及其安全性，可以参阅往期博文：

• Session的工作机制及安全性分析

  

三、无状态令牌：Token

为降低服务端压力，Token 方案将用户数据编码后全量存储于客户端：

示例：token = base64(用户ID) + "." + base64(过期时间) + "." + HMAC签名。

• 原理：
  • 用户登录后，服务端生成Token（含用户信息+签名）返回客户端；
  • 客户端存储Token（Cookie/LocalStorage），每次请求通过Header（如 Authorization: Bearer <token>）提交；
  • 服务端验证签名及有效期。
• 优势：
  • 无状态：服务端无需存储会话数据，适合分布式系统；
  • 灵活性：Token可存储任意客户端（App/浏览器）。
  • 签名防篡改：使用密钥（如HMAC-SHA256）生成签名，确保数据完整性。
• 安全风险：Token泄露可能导致长期未授权访问。

四、标准化令牌：JWT（JSON Web Token）

为解决Token格式混乱问题，JWT 提供标准化、自包含的令牌格式：

• 结构（三段式）：

  1. Header：算法（如HS256）和类型（JWT）；
  2. Payload：用户数据（如 {"sub": "user123"}）；
  3. Signature：对前两段的签名。

• 特性：

  • 自包含：服务端直接解码Payload获取用户信息，无需查库；
  • 标准化：支持跨语言/平台。

• 局限：

  • 不可撤销：颁发后需等待过期（除非服务端维护黑名单）；
  • 数据膨胀：频繁携带大数据增加网络开销。

若想了解JWT的工作机制及其安全性，可以参阅往期博文：

• 一文看懂JWT如何重塑网络身份认证：从“身份证”到“数字令牌”

五、企业级统一认证：单点登录（SSO）

为解决多系统重复登录问题，SSO 基于Token/JWT实现跨系统身份共享：

• 原理：
  1. 用户访问系统A，重定向至SSO认证中心；
  2. 登录成功后，SSO颁发Token（或Ticket）并存储为Cookie；
  3. 用户访问系统B时，SSO验证已有Token，自动登录。
• 依赖技术：
  • Token/JWT作为身份传递载体；
  • Cookie实现SSO域名下的凭证共享。
• 优势：
  • 一次登录，访问所有关联系统；
  • 集中管理用户权限。

示例：企业内网中，登录OA系统后无需再输入密码即可访问CRM、财务系统。

若想了解SSO的工作流程及具体实现方式，可以参阅往期博文：

• 什么是单点登录SSO？有哪些常用的实现方式？

六、技术对比与演进总结

技术	核心思想	适用场景	关键演进点
Cookie	客户端存储标识	基础状态保持	HTTP无状态的基石
Session	服务端存储状态+ID映射	传统Web应用	解决敏感数据存储
Token	客户端自包含数据+签名验证	分布式/API服务	无状态解放服务端
JWT	标准化Token格式	跨平台认证（如微服务）	自包含减少查库
SSO	集中认证+多系统共享	企业级多应用集成	基于Token实现身份中继

演进逻辑：
1、Cookie → Session（状态服务端化） → Token（无状态化） → JWT（标准化） → SSO（多系统集成）
2、本质是 存储位置（客户端/服务端）与 状态管理（有状态/无状态）的持续优化。

实战选择建议：

• 简单系统：Session + Cookie（易实现）
• 分布式/API服务：JWT（无状态扩展性强）
• 多系统集成：SSO + JWT（统一认证）
• 安全加固：
  • Cookie 启用 HttpOnly + Secure；
  • JWT 设置短有效期，配合Refresh Token续期。

---

关注我，带你用“人话”读懂技术硬核！ 🔥