身份认证技术对比：Session、JWT、Token、SSO、OAuth 2.0

前言

在 Web 应用中，身份认证和授权是核心安全机制。本文简明扼要地对比五种常见的认证方案，帮助你快速理解它们的区别和适用场景。

一、Session（会话）

工作原理

• 用户登录后，服务器创建会话并存储在服务端（内存、数据库或 Redis）
• 服务器返回 Session ID 给客户端，通常存储在 Cookie 中
• 后续请求携带 Session ID，服务器通过 ID 查找会话数据验证身份

特点

• 有状态：服务器需要存储会话信息
• 安全性高：敏感数据存储在服务端
• 可控性强：服务器可随时销毁会话

缺点

• 扩展性差：分布式系统需要会话共享（如 Redis）
• 服务器压力大：需要存储大量会话数据
• 跨域困难：Cookie 受同源策略限制

适用场景

传统单体应用、需要强控制的企业内部系统

---

二、JWT (JSON Web Token)

工作原理

• 用户登录后，服务器生成包含用户信息的 JWT
• JWT 由三部分组成：Header（头部）、Payload（载荷）、Signature（签名）
• 客户端存储 JWT（通常在 localStorage 或 Cookie）
• 后续请求在 Header 中携带 JWT，服务器验证签名即可

特点

• 无状态：服务器不存储任何会话信息
• 自包含：Token 本身包含用户信息
• 跨域友好：可通过 HTTP Header 传递
• 扩展性好：适合分布式和微服务架构

缺点

• 无法主动失效：Token 在过期前始终有效
• Token 体积大：包含用户信息，每次请求都传输
• 安全风险：如果泄露，在过期前无法撤销

适用场景

微服务架构、RESTful API、移动应用、跨域应用

---

三、Token（令牌）

概念说明

Token 是一个通用概念，指代表用户身份的凭证。JWT 是 Token 的一种具体实现。

常见类型

• Opaque Token（不透明令牌）：随机字符串，需要服务器查询数据库验证
• JWT：自包含的令牌
• Access Token：访问令牌，用于访问资源
• Refresh Token：刷新令牌，用于获取新的 Access Token

特点

• Token 可以是有状态的（需要服务器验证）或无状态的（如 JWT）
• 通常通过 HTTP Header 传递：Authorization: Bearer <token>

适用场景

API 认证、第三方集成、移动应用

---

四、SSO (Single Sign-On，单点登录)

工作原理

• 用户在认证中心登录一次
• 访问其他关联系统时，认证中心验证身份并颁发凭证
• 各系统信任认证中心，无需重复登录

常见实现方式

• CAS（Central Authentication Service）
• SAML（Security Assertion Markup Language）
• 基于 OAuth 2.0 / OpenID Connect

特点

• 一次登录，多处使用
• 集中管理用户身份
• 提升用户体验

缺点

• 实现复杂：需要统一认证中心
• 单点故障：认证中心宕机影响所有系统
• 安全风险：一旦凭证泄露，所有系统受影响

适用场景

企业内部多系统集成、大型平台（如 Google、Microsoft 账号登录多个服务）

---

五、OAuth 2.0

工作原理

OAuth 2.0 是一个授权框架，不是认证协议。它允许第三方应用在不获取用户密码的情况下访问用户资源。

核心角色

• Resource Owner（资源所有者）：用户
• Client（客户端）：第三方应用
• Authorization Server（授权服务器）：颁发 Token
• Resource Server（资源服务器）：存储用户资源

授权流程（以授权码模式为例）

1. 用户访问第三方应用，点击"使用 Google 登录"
2. 跳转到 Google 授权页面，用户同意授权
3. Google 返回授权码给第三方应用
4. 第三方应用用授权码换取 Access Token
5. 第三方应用使用 Token 访问用户资源（如头像、邮箱）

特点

• 授权而非认证：OAuth 2.0 本身不验证用户身份，只授权访问资源
• 安全：第三方应用无需知道用户密码
• 灵活：支持多种授权模式（授权码、隐式、密码、客户端凭证）

与 OpenID Connect 的关系

• OpenID Connect 是基于 OAuth 2.0 的认证层，补充了身份认证功能
• OAuth 2.0 解决"授权"问题，OpenID Connect 解决"认证"问题

适用场景

第三方登录（如"使用微信登录"）、API 授权、跨平台资源共享

---

对比总结

---

实际应用建议

选择 Session

• 传统单体应用
• 需要强会话控制（如强制下线）
• 安全性要求极高的场景

选择 JWT

• 微服务架构
• 移动应用或 SPA（单页应用）
• 跨域 API 调用
• 需要无状态扩展

选择 SSO

• 企业内部有多个系统
• 需要统一用户管理
• 提升用户体验（一次登录）

选择 OAuth 2.0

• 第三方登录（如"使用 GitHub 登录"）
• 需要访问第三方资源（如读取用户 Google Drive 文件）
• 开放 API 给第三方开发者

---

混合使用

实际项目中，这些技术常常组合使用：

• JWT + Refresh Token：Access Token 短期有效，Refresh Token 长期有效，平衡安全性和用户体验
• SSO + JWT：认证中心颁发 JWT，各系统验证 JWT
• OAuth 2.0 + JWT：OAuth 2.0 颁发的 Access Token 使用 JWT 格式
• Session + OAuth 2.0：用户通过 OAuth 2.0 登录后，服务器创建 Session

---

总结

• Session：传统、有状态、服务器存储
• JWT：现代、无状态、自包含
• Token：通用概念，JWT 是其一种实现
• SSO：一次登录，多处使用
• OAuth 2.0：授权框架，用于第三方访问资源