lab/note/资源/网络/认证.md

Cookie

维度	说明
本质	存储在浏览器端的一小段文本数据（通常 4KB 以内）
核心机制	浏览器在每次 HTTP 请求中自动携带符合域名/路径规则的 Cookie
关键属性	HttpOnly（防 JS 读取）、Secure（仅 HTTPS）、SameSite（防 CSRF）、Expires/Max-Age
定位	传输载体，而非认证方案本身——它负责把令牌（Session ID 或 Token）在客户端和服务器之间来回搬运

优点：

• 简单成熟，几乎所有 Web 框架默认集成
• 服务端可随时销毁会话，控制力强
• 敏感信息存在服务端，不暴露给客户端

缺点：

• 扩展性受限——多服务器需共享 Session（引入 Redis 等外部存储）
• 依赖 Cookie，纯移动端/非浏览器环境不友好
• 容易受到 CSRF 攻击（需额外防护）

Session

维度	说明
本质	服务器端维护的用户会话数据（通常以 Map 结构存在内存、Redis 或数据库中）
认证流程	用户登录 → 服务器创建 Session → 将 Session ID 通过 Set-Cookie 返回 → 浏览器后续请求自动携带该 Cookie → 服务器通过 Session ID 查找会话数据验证身份
核心特点	有状态：服务器持有用户上下文，可随时主动吊销
定位	经典的服务端主导的认证方式，适合传统 Web 应用和前后端未彻底分离的场景

优点：

• 简单成熟，几乎所有 Web 框架默认集成
• 服务端可随时销毁会话，控制力强
• 敏感信息存在服务端，不暴露给客户端

缺点：

• 扩展性受限——多服务器需共享 Session（引入 Redis 等外部存储）
• 依赖 Cookie，纯移动端/非浏览器环境不友好
• 容易受到 CSRF 攻击（需额外防护）

JWT

本质	一段经过签名（或加密）的 JSON 数据，由 Header、Payload、Signature 三部分组成，以 Base64URL 编码
认证流程	用户登录 → 服务器验证凭据并签发 JWT → 客户端存储 Token → 后续请求在 Authorization: Bearer <token> 头中携带 → 服务器仅验证签名和有效期，无需查库
核心特点	无状态：Token 自身包含用户身份信息，服务器不需要维护会话
定位	现代前后端分离架构和多端（Web/iOS/Android）统一接入的事实标准

优点：

• 天然无状态，服务端可随意水平扩展
• 不依赖 Cookie，可用于移动端、小程序等非浏览器环境
• 跨域友好（CORS 场景下比 Cookie 更灵活）
• Payload 可携带少量业务数据，减少数据库查询

缺点：

• Token 一旦签发，在过期前无法主动撤销（需引入黑名单/版本号等机制）
• Payload 仅 Base64 编码（非加密），敏感信息绝对不能放入
• Token 体积比 Session ID 大，每次请求都传输有一定带宽开销

SSO

维度	说明
本质	一种架构模式，通过统一的认证中心（IdP），让用户在多个独立系统间共享登录状态
认证流程	用户访问应用A → 重定向到 SSO 认证中心 → 登录并获取令牌 → 带回令牌访问应用A → 再访问应用B时，认证中心识别已登录状态，直接放行
常见实现	CAS、SAML、OAuth 2.0 + OpenID Connect
定位	企业级、多系统生态的统一身份认证方案

优点：

• 用户体验极佳：一次登录，访问所有关联系统
• 集中管理：统一账号体系、权限策略、安全审计
• 安全性提升：减少密码泄露面，可配合多因素认证（MFA）

缺点：

• 单点故障风险：认证中心一旦宕机，所有系统登录受影响
• 实现复杂：涉及协议配置、令牌传递、跨域重定向等
• 对认证中心的高可用要求极高

OAuth 2.0

维度	说明
本质	一种授权框架（而非纯粹的认证协议），允许用户授权第三方应用在不暴露自己密码的情况下访问受保护资源
核心角色	资源拥有者（用户）、客户端（第三方应用）、授权服务器、资源服务器
核心流程	用户授权 → 第三方获取授权码 → 换取 Access Token → 持 Token 访问资源
定位	第三方接入和开放平台的标准授权方案（微信登录、Google 登录等）