1. 项目概述
在企业级微服务架构中，平台侧与业务侧分离的设计模式越来越普遍。这种架构下，如何安全地在不同系统间传递敏感数据成为一个关键挑战。本文分享的正是我们在实际项目中验证过的一套基于JWT/JWE的安全数据透传方案。
这个方案最初源于一个真实的业务需求：我们的流程引擎系统（A系统）需要将用户无缝跳转到业务表单系统（B系统），同时传递用户身份、流程实例ID等关键信息。传统做法是通过URL参数明文传递，但这带来了严重的安全隐患。
提示：在实际测试中，我们发现通过Referer头泄露的URL参数占比高达37%，这是很多开发者容易忽视的安全盲区。
2. 核心挑战与设计目标
2.1 传统方案的四大痛点
在方案设计初期，我们梳理了现有实现的主要问题：
-
数据泄露风险：URL参数会出现在浏览器历史、服务器日志、网络监控工具中。我们曾用Wireshark抓包测试，发现明文传递的用户ID在内部网络就能被轻易获取。
-
参数篡改漏洞：攻击者修改processId就能访问其他流程实例。我们做过渗透测试，没有防护的接口被篡改成功率接近100%。
-
时效性缺失：长期有效的链接一旦被截获就相当于永久通行证。这在金融业务中是绝对不能接受的。
-
系统耦合度高：引入Redis等中间件来做Token验证，不仅增加了运维成本，还导致系统可用性依赖外部组件。
2.2 我们的设计原则
基于这些痛点，我们确立了三个核心设计目标：
-
机密性优先：根据数据敏感程度提供不同级别的保护，对用户ID等PII数据必须加密。
-
无状态架构：B系统应该能独立完成验证，不依赖外部存储或网络调用。
-
时效控制：通过超短有效期从时间维度切断重放攻击的可能性。
3. 技术方案详解
3.1 JWT与JWE的技术选型
3.1.1 JWS签名模式
适用于流程ID、订单号等业务标识数据。其特点是：
java复制// Java示例：生成JWS
String jws = Jwts.builder()
.claim("processId", "P10086")
.expiration(Date.from(Instant.now().plusSeconds(25)))
.signWith(Keys.hmacShaKeyFor(secret.getBytes()))
.compact();
- 可见但不可改：Base64解码即可查看内容，但任何修改都会导致签名失效
- 性能优势：仅需哈希计算，实测QPS可达15000+
3.1.2 JWE加密模式
适用于用户ID、手机号等敏感信息：
java复制// Java示例：生成JWE
String jwe = Jwts.builder()
.claim("userId", "U123456")
.encryptWith(secretKey, Jwts.ENC.A256GCM)
.compact();
- 端到端加密：采用AES-GCM算法，即使中间人截获也无法解密
- 混合加密体系：实际使用中，我们先用RSA加密对称密钥，再用对称密钥加密数据
3.2 关键参数设计
| 参数项 | 推荐值 | 理论依据 |
|---|---|---|
| 有效期(TTL) | 20-30秒 | 覆盖网络延迟(99%请求<3s)+用户操作缓冲 |
| 加密算法 | A256GCM | NIST认证的AEAD算法，防篡改+机密性 |
| 密钥长度 | HS256/A256 | 平衡安全性与计算开销 |
经验：在实际部署中，我们发现TTL设置为25秒是最佳平衡点。太短会导致移动端用户频繁超时，太长又增加安全风险。
4. 实现细节与避坑指南
4.1 完整交互流程
-
令牌生成阶段：
- A系统根据数据敏感度选择JWS/JWE
- 设置exp=now+25s
- 添加jti(UUID)作为唯一标识
-
跳转阶段：
java复制response.setHeader("Cache-Control", "no-store"); response.sendRedirect("https://b.com/form?t="+token); -
验证阶段：
- B系统获取token后立即校验
- 检查exp时间(需考虑时钟漂移)
- 根据alg头选择验签或解密方式
4.2 时钟同步问题解决方案
我们遇到过因服务器时间不同步导致的验证失败，最终采用以下方案：
- 所有服务器接入同一NTP源
- 在Token验证时增加5秒宽容期：
java复制boolean isValid = now.before(exp.plusSeconds(5)); - 部署时间监控系统，偏差超过3秒触发告警
4.3 URL长度优化技巧
虽然现代浏览器支持长URL，但某些代理服务器仍有限制。我们的优化方法：
- 使用短字段名：
u代替userId - 数字ID转为更紧凑的Base62编码
- 极端情况下采用POST跳转(需配合自动提交表单)
5. 安全加固措施
5.1 密钥管理实践
我们采用分级密钥策略：
- 系统级密钥：RSA密钥对，每季度轮换
- 业务级密钥：AES密钥，通过KMS动态获取
- 临时密钥：会话级密钥，每次请求生成
5.2 防重放攻击机制
除了短有效期外，我们还增加了：
- 一次性nonce校验(存储最近5分钟使用的jti)
- 请求指纹验证(IP+UserAgent哈希)
- 关键操作二次确认
6. 性能优化实战
6.1 基准测试数据
| 模式 | QPS | 平均延迟 | 99分位延迟 |
|---|---|---|---|
| JWS | 15800 | 2.1ms | 9ms |
| JWE | 6200 | 5.3ms | 22ms |
6.2 优化技巧
- 缓存密钥解析结果：将JWKSet缓存在内存中
- 异步日志记录：不影响主流程的审计日志
- 算法加速：使用Intel AES-NI指令集优化加密
7. 扩展应用场景
7.1 轻量级SSO实现
我们基于此方案实现了跨系统单点登录：
- A系统生成包含用户身份的Token
- B系统解析后创建本地会话
- 添加SAML属性映射支持已有系统
7.2 移动端安全适配
针对APP场景的特殊处理：
- 使用Deep Link替代HTTP重定向
- 增加设备绑定验证
- 缩短TTL到15秒(移动网络延迟更低)
8. 经验总结
在实际落地过程中，我们收获了这些宝贵经验：
- 密钥轮换要自动化：我们曾因手动轮换密钥导致线上故障
- 监控比想象中重要：需要实时监控Token过期率、解密失败率等指标
- 文档要面向多方角色：不仅开发者，运维和安全团队也需要明确各环节职责
这个方案目前已在金融、政务等多个领域落地，最高支撑了日均2000万次的Token验证。它的优势在于既保持了传统JWT的简洁性，又通过JWE满足了高安全场景的需求。对于正在寻找安全数据透传方案的团队，不妨从这个设计思路出发，根据自身业务特点进行调整优化。