3. 令牌技术概览：Session-Cookie、JWT、OAuth2 Token、SAML Assertion 的对比
在构建认证授权平台与 SSO 系统时，选择正确的令牌技术是架构设计的核心决策点。不同的令牌方案在存储方式、数据结构、验证效率、跨域能力以及安全模型上存在本质差异。本节将从架构视角出发，系统对比四种主流令牌技术：Session-Cookie、JWT、OAuth2 Token 与 SAML Assertion。
3.1 四种令牌技术核心特征对比
下表从数据结构、存储位置、验证方式、跨域支持、生命周期管理及典型场景六个维度进行横向对比：
| 对比维度 | Session-Cookie | JWT | OAuth2 Token | SAML Assertion |
|---|---|---|---|---|
| 数据结构 | 服务端 Session 对象（任意格式） | JSON 三段式（Header.Payload.Signature） | 通常为不透明字符串（Bearer Token） | XML 格式（包含断言、条件、属性） |
| 存储位置 | 服务端内存/Redis/DB；客户端仅存 Session ID | 客户端（浏览器/移动端） | 客户端（内存/本地存储） | 客户端（HTTP POST 或 URL 参数传递） |
| 验证方式 | 服务端查 Session 存储（状态ful） | 本地验签（无状态） | 需调用授权服务器内省端点（状态ful 或 JWT 格式） | 需验证 XML 签名及信任链（状态ful） |
| 跨域支持 | 弱（受 Cookie 同源策略限制） | 强（Token 可放在 Authorization Header） | 强（支持授权码、客户端凭证等多种流程） | 中（依赖 HTTP POST Binding 或 Redirect） |
| 生命周期管理 | 服务端主动销毁 Session | 到期前无法主动撤销（需黑名单） | 支持 Refresh Token 轮换与撤销 | 通常短时效（分钟级），依赖 IdP 控制 |
| 典型场景 | 单体应用、传统 Web 应用 | 微服务 API 网关、无状态认证 | 第三方授权、移动端、开放 API | 企业级 SSO、跨组织联邦身份 |
架构决策要点： 选择令牌技术时，需优先评估系统是否需要无状态验证（JWT 优势）、是否需要第三方授权委托（OAuth2 优势）、是否需要跨组织联邦身份（SAML 优势）。Session-Cookie 在微服务架构中扩展性受限，但在单体应用中仍是最简洁的方案。
3.2 四种令牌技术架构对比图
下图从架构视角展示了四种令牌技术在典型部署场景中的交互流程与核心差异：
3.3 Session-Cookie：经典的有状态方案
Session-Cookie 是最传统的 Web 认证方案。用户登录后，服务端创建 Session 对象并返回 Session ID，客户端通过 Cookie 携带该 ID 访问后续请求。
- 优点：实现简单，服务端可主动销毁 Session，安全性高（敏感数据不暴露给客户端）。
- 缺点：服务端需维护 Session 存储，水平扩展时需共享 Session（如 Redis），跨域场景受限。
- 架构建议：适合单体应用或小型团队项目；在微服务架构中，建议使用网关统一 Session 管理或迁移至 JWT。
3.4 JWT：无状态令牌的利与弊
JWT（JSON Web Token）将用户信息编码在 Token 本身，服务端无需存储 Session，通过验签即可完成认证。
// JWT 结构示例
// Header
{
"alg": "RS256",
"typ": "JWT"
}
// Payload
{
"sub": "user_12345",
"name": "张三",
"iat": 1718000000,
"exp": 1718003600,
"roles": ["admin", "editor"]
}
// Signature（使用 RSA 私钥签名）
架构提示： JWT 的无状态特性使其在微服务 API 网关场景中极具优势，但需注意 Token 泄露风险。建议使用短时效（如 15 分钟）配合 Refresh Token 机制，并避免在 Payload 中存放敏感数据。
3.5 OAuth2 Token：委托授权的工业标准
OAuth2 不是单一的令牌格式，而是一套授权框架。其 Token 通常为不透明字符串（Bearer Token），也可采用 JWT 格式（称为 JWT Access Token）。
- 授权码流程（Authorization Code）： 最安全的流程，适用于第三方应用获取用户授权。
- 客户端凭证流程（Client Credentials）： 适用于服务间通信，无需用户参与。
- 刷新令牌（Refresh Token）： 允许客户端在 Access Token 过期后获取新 Token，无需用户重新登录。
3.6 SAML Assertion：企业联邦身份基石
SAML（Security Assertion Markup Language）使用 XML 格式的断言（Assertion）传递身份信息，广泛应用于企业级 SSO 和跨组织联邦身份场景。
<!-- SAML Assertion 简化示例 -->
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_a1b2c3d4" IssueInstant="2024-06-10T10:00:00Z">
<saml:Issuer>https://idp.example.com</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
zhang.san@example.com
</saml:NameID>
</saml:Subject>
<saml:Conditions NotBefore="2024-06-10T09:55:00Z"
NotOnOrAfter="2024-06-10T10:05:00Z"/>
<saml:AuthnStatement AuthnInstant="2024-06-10T10:00:00Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
注意： SAML 的 XML 签名验证和信任链配置较为复杂，建议在架构中引入成熟的 SAML 库（如 Shibboleth、SimpleSAMLphp）或使用身份即服务（IDaaS）平台简化集成。
3.7 架构选型决策树
以下决策树可帮助架构师根据系统特征快速选择令牌技术：
3.8 混合架构实践
在实际大型系统中，往往需要组合使用多种令牌技术。例如：
- 前端 + API 网关： 使用 OAuth2 授权码流程获取 Access Token（JWT 格式），网关验签后转发至后端微服务。
- 企业 SSO 集成： 使用 SAML Assertion 从企业 IdP 获取身份，内部系统转换为 JWT 供微服务使用。
- 遗留系统适配： 通过 Session-Cookie 与 JWT 的桥接模式，逐步迁移至无状态架构。
架构总结： 没有银弹。Session-Cookie 适合简单场景，JWT 适合无状态 API，OAuth2 适合授权委托，SAML 适合企业联邦。架构师应根据系统的跨域需求、扩展性要求、安全等级和团队维护能力，选择最合适的令牌方案或组合策略。