身份认证协议解析

原创已于 2025-05-30 16:47:37 修改 · 969 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#安全

于 2025-05-30 16:44:26 首次发布

1. 引言

现代服务身份认证机制作为服务安全保障的核心，本篇文章介绍一些常用的身份认证原理及对比

2. 认证协议详解

2.1 JWT（JSON Web Token）

技术原理

无状态令牌：基于JSON的开放标准（RFC 7519），由Header.Payload.Signature三部分组成，使用密钥（HMAC/RSA）签名防篡改。
包含信息：Payload可直接存储用户ID、角色、过期时间等信息，减少数据库查询。

运行逻辑

1. 用户登录 → 服务端验证 → 生成JWT（签名） → 返回客户端
2. 客户端存储JWT（Cookie/LocalStorage） → 后续请求携带JWT
3. 服务端验签 → 解析Payload → 授权访问资源

优势

✅ 无状态：适合分布式架构，减轻服务端存储压力。
✅ 跨域友好：适用于微服务、API网关。
✅ 灵活性：Payload可扩展自定义字段（如用户角色）。

劣势

❌ Token泄露风险：XSS攻击可能窃取LocalStorage中的Token。
❌ 无法主动吊销：需依赖短有效期或黑名单（如Redis）。

使用场景

前后端分离应用（React + REST API）。
微服务间身份传递（如Kubernetes服务调用）。

2.2 Session

技术原理

有状态会话：服务端存储Session（内存/Redis），客户端通过Cookie携带Session ID。
依赖服务端存储：Session ID与用户数据绑定。

运行逻辑

1. 用户登录 → 服务端创建Session → 返回Session ID（Set-Cookie）
2. 客户端后续请求携带Session ID → 
3. 服务端查询Session数据 → 授权访问

优势

✅ 可控性强：可随时吊销会话（删除Session）。
✅ 成熟稳定：适合传统Web应用。

劣势

❌ 有状态：横向扩展需共享存储（如Redis集群）。
❌ CSRF风险：需配合CSRF Token防护。

使用场景

服务端渲染应用（如Spring MVC、Django）。
需要严格会话管理的系统（如银行后台）。

2.3 OAuth 2.0

技术原理

授权框架：用户通过第三方（如Google）授权应用访问资源，而非直接共享密码。
核心角色：
- Resource Owner：用户。
- Client：第三方应用。
- Authorization Server：如Google OAuth。
- Resource Server：如Google API。

运行逻辑（授权码模式）

1. 用户点击“用Google登录” → 跳转Google授权页 → 
2. 用户授权 → 返回授权码（Code） → 
3. 客户端用Code + Secret换Access Token → 
4. 客户端用Token访问API（如获取用户邮箱）

优势

✅ 无需暴露密码：降低用户凭证泄露风险。
✅ 标准化：支持Web/移动/服务端。

劣势

❌ 复杂性：需理解4种授权模式（如PKCE防中间人攻击）。
❌ Token管理：泄露后可能被滥用。

使用场景

第三方登录（如“用GitHub账号登录”）。
API授权（如调用Twitter API）。

2.4 SSO（单点登录）

技术原理

一次登录，多系统通行：依赖中央认证服务（如CAS、SAML）。
核心组件：
- IdP（身份提供商）：如Okta、Azure AD。
- SP（服务提供商）：如企业内网应用。

运行逻辑（SAML流程）

1. 用户访问App A → 重定向到IdP → 
2. IdP认证（如AD/LDAP）→ 生成SAML断言 → 
3. 用户携带断言返回App A → 
4. App A验签后授权

优势

✅ 用户体验好：无需重复登录。
✅ 集中管理：统一权限控制。

劣势

❌ 配置复杂：需IdP与SP元数据对接。
❌ 依赖网络：IdP故障影响所有系统。

使用场景

企业内网SSO（如Office 365、Salesforce）。

3. 协议对比与选型建议

认证方式	状态管理	安全性	适用场景	典型用例
JWT	无状态	中高	分布式API、微服务	React + Node.js
Session	有状态	中	传统Web应用	银行后台系统
OAuth 2.0	混合	高	第三方登录、API授权	GitHub登录、微信登录
SSO	有状态	高	企业多系统统一认证	企业内网各服务