当前位置：首页 > wzjs >正文

建网站市场厦门百度公司

wzjs 2025/9/11 16:13:09

建网站市场,厦门百度公司,做的网站怎样适配手机,百度电脑版网页版认证鉴权中会反复提到COOKIE、SESSION、TOKEN、JWT、SSO，你能说出他们之间的区别与联系么？接下来跟随博主的视角一一理清。一、HTTP 无状态性与基础解决方案：Cookie HTTP 协议天然无状态，每次请求独立，无法自动关联用…

认证鉴权中会反复提到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

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）

样例：左侧为JWT字符串，右侧为解码后的JWT

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

结构（三段式）：
1. Header：算法（如HS256）和类型（JWT）；
2. Payload：用户数据（如 {"sub": "user123"}）；
3. Signature：对前两段的签名。
特性：
- 自包含：服务端直接解码Payload获取用户信息，无需查库；
- 标准化：支持跨语言/平台。
局限：
- 不可撤销：颁发后需等待过期（除非服务端维护黑名单）；
- 数据膨胀：频繁携带大数据增加网络开销。

JWT典型流程

若想了解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实现身份中继