先说我为什么会对这个题目感兴趣。最近在做一个跨系统的数据对接项目业务方提了一个很硬的要求所有跨系统调用里涉及的敏感字段不管走内网还是公网都不能在任何一个中间环节出现明文同时接收方必须能验证数据确实来自合法来源且没有被篡改。这个需求听起来不复杂真正落地时要同时解决四个问题身份可信、数据机密、防重放、密钥可轮换。我最终的选型就是基于 JWT/JWE 的跨系统安全数据透传方案——用 JWT 承载身份与数据的可信性用 JWE 解决敏感载荷的机密性两者嵌套组成一个完整的透传令牌。这篇文章适合正在做系统集成、微服务间数据交换、开放平台接口对接的后端和运维同学参考也适合安全工程师做方案评审时当一份现成的踩坑清单。1. 为什么跨系统透传需要 JWT/JWE 这套组合1.1 透传场景里的三个典型痛点我先把问题还原一下。所谓“跨系统数据透传”最常见的形式就是系统 A 拿到一份数据原封不动或者稍作处理后传给系统 B、系统 C。最原始的方案是 A 把数据 POST 给 BB 存库C 再来拉。但随着系统多了你会发现三个痛点特别明显。第一个痛点是“数据在链路上裸奔”。很多企业内网默认是可信的结果一份包含手机号、身份证号、银行卡号的 JSON 就明文躺在消息队列或者接口日志里。运维查问题方便了安全审计来的时候大家都不好看。第二个痛点是“接收方无法证明数据来源”。A 传了一份订单给 BB 怎么知道这份订单真是 A 生成的而不是某个内部人员手工构造的假请求光靠内网 IP 白名单说实话约等于没有。第三个痛点是“中间环节不可控”。数据可能会经过网关、缓存、消息中间件、日志采集器任何一个环节都可能有意无意地读到业务字段。这时候你就需要一种机制中间的管道只负责搬运搬的是什么完全看不懂只有最终接收方能解开。这三个痛点叠加起来纯 HTTPS 解决不了。HTTPS 保证的是“客户端和服务端之间这条链路不泄露”但数据一旦进了服务端在日志里、在缓存里、在下一个内部调用里它仍然是明文。所以你需要的是一个“端到端加密 来源认证”的载体而 JWT/JWE 嵌套结构正好是干这个的。1.2 JWT 与 JWE 的分工签名保证可信加密保证机密很多人一开始会混淆 JWT 和 JWE其实这两者解决的问题完全不同。JWT 全称是 JSON Web Token它本身默认是一段 Base64URL 编码的 JSON包含 Header、Payload、Signature 三段。JWT 的核心价值是签名用 HMAC 或者 RSA/ECDSA 对 Header 和 Payload 做摘要接收方验证签名就能确认数据没被改过并且确实来自持有对应密钥的一方。但注意JWT 默认是“不加密”的Payload 里那串 Base64URL 一解码就是明文所以 JWT 适合放“不敏感但需要防篡改”的信息比如用户 ID、角色、过期时间。JWE 全称是 JSON Web Encryption它才是真正做机密性的。JWE 同样是一串 Base64URL 拼接的 Compact 串但结构变成了五段Header、Encrypted Key、Initialization Vector、Ciphertext、Authentication Tag。它把真正的业务数据加密成密文并且附带完整性校验接收方用私钥或者对称密钥解出来才能看到内容。我最终的方案是“先签后加密”内层先构造一个带签名的 JWT里面放业务数据外层再用 JWE 把整个 JWT 串加密。这样接收方拿到令牌后先解 JWE 得到内层 JWT再验 JWT 签名。加密保证传输和存储环节没人能看到明文签名保证解密之后的内容确实来自可信签发方。这两层互为补充缺一个都不完整。1.3 为什么不是我直接用 HTTPS 自定义加密有人会问我直接用 HTTPS然后在 Body 里自定义一个 AES 加密字段不就行了当然可以很多老系统就是这么干的。但问题在于自定义加密没有标准每个团队写出来的都不一样后续维护就是灾难。A 系统用 AES/ECB/PKCS5PaddingB 系统用 AES/GCMC 系统在密钥里拼接了一个固定盐D 系统直接在代码里写死密钥安全评审的时候我看过太多这种代码血压容易高。JWE 的好处是这套加密流程是标准化的算法标识、密钥管理方式、加密模式、完整性校验都有 RFC 规范不同语言、不同框架之间可以互认。比如 Java 的 nimbus-jose-jwt、Node 的 jose 库、Go 的 go-jose实现的是同一套标准A 系统发出的 JWEB 系统一定能解前提是密钥配对正确。跨团队、跨语言、跨系统这比自研加密方案靠谱得多。2. 核心设计先验签后解密的双层令牌结构2.1 一个透传令牌应该长什么样我先给出一份可以直接落地的令牌结构设计。内层 JWT 的 Claims 建议这样规划Claims 字段含义是否必填说明iss签发方标识是比如 system-a接收方用它做来源白名单判断sub数据主体标识是比如 userId 或订单号便于接收方关联业务aud接收方标识是防止令牌被拿到其他系统重放exp过期时间是建议 5 到 15 分钟透传场景不需要长时效iat签发时间是配合 exp 做时效校验jti令牌唯一 ID是用于防重放记录接收方落库去重bizData业务载荷否放真正要透传的数据建议限制大小nonce随机数是增加密文随机性防止相同数据产生相同密文外层 JWE Header 我通常会加两个自定义参数kid 表示解密密钥版本cty 固定为 JWT 表示内层是 JWT。这样接收方拿到令牌后第一件事就是读 kid 找到对应的解密私钥解完再按 iss 找到签发方公钥验签流程非常清晰。2.2 JOSE Header 参数怎么选选算法的时候我建议遵循一个原则能用现代算法就不要迁就老系统。内层签名算法对称场景最简单的是 HS256但 HS256 要求签发方和接收方共享同一个 HMAC 密钥跨系统一旦有一方泄露密钥所有系统全部沦陷所以我更推荐 RS256 或 PS256用非对称密钥对签发方持有私钥接收方只保存公钥验签。如果性能敏感并且双方都在自己的可信域内也可以考虑 EdDSA但兼容性需要考虑。外层加密算法我推荐 RSA-OAEP-256 做密钥封装A256GCM 做内容加密。RSA-OAEP-256 是 RSA-OAEP 的一种参数组合比老旧的 RSA1_5 安全得多A256GCM 是 AES-GCM 模式自带完整性校验密文长度等于明文长度加上 16 字节的认证标签不会膨胀太多。如果你对性能要求极高也可以直接用 ECDH-ES 做密钥协商但那要求接收方预先提供椭圆曲线公钥集成成本会高一些。2.3 密钥体系与算法选型表我把常见的算法组合整理成一张表方便你做选型用途推荐算法场景说明密钥管理方式内层签名RS256/PS256签发方私钥签名接收方公钥验签签发方保管私钥接收方存公钥外层加密RSA-OAEP-256 A256GCM接收方公钥加密接收方私钥解密接收方保管私钥签发方存接收方公钥对称备选HS256 A256CBC-HS512跨系统数量少且双方可控双方共享密钥建议通过密钥管理系统轮换异步高性能EdDSA ECDH-ES高并发、极低延迟密钥协商对需要双方预先交换公钥这里有个容易忽略的点在跨系统透传方案里签发方和接收方的密钥诉求是不对称的。签发方需要“自己的私钥”来签 JWT同时需要“接收方的公钥”来加密 JWE接收方需要“自己的私钥”来解 JWE同时需要“签发方的公钥”来验签。所以密钥交换是双向的别只给对面一个公钥就完事那会导致后期解密验签全失败。3. 实操签发、透传、接收全链路实现3.1 签发端实现JWE 加密我用 Java 的 nimbus-jose-jwt 库来演示因为这个库在 JOSE 标准覆盖度和社区活跃度上都比较稳。签发端要做两件事先构造并签名内层 JWT再用接收方公钥加密成 JWE。import com.nimbusds.jose.*; import com.nimbusds.jose.crypto.*; import com.nimbusds.jwt.*; import java.security.interfaces.RSAPrivateKey; import java.security.interfaces.RSAPublicKey; import java.util.Date; import java.util.UUID; public class JweTokenIssuer { private final RSAPrivateKey signerPrivateKey; private final RSAPublicKey recipientPublicKey; public JweTokenIssuer(RSAPrivateKey signerPrivateKey, RSAPublicKey recipientPublicKey) { this.signerPrivateKey signerPrivateKey; this.recipientPublicKey recipientPublicKey; } public String issueToken(String subject, String audience, String bizData) throws JOSEException { // 1. 构建内层 JWT Claims long now System.currentTimeMillis(); JWTClaimsSet innerClaims new JWTClaimsSet.Builder() .issuer(system-a) .subject(subject) .audience(audience) .expirationTime(new Date(now 10 * 60 * 1000)) .issueTime(new Date(now)) .jwtID(UUID.randomUUID().toString()) .claim(bizData, bizData) .claim(nonce, UUID.randomUUID().toString()) .build(); // 2. 内层 JWT 用 RSA 私钥签名 JWSHeader jwsHeader new JWSHeader.Builder(JWSAlgorithm.RS256) .keyID(sign-key-v1) .build(); SignedJWT signedJWT new SignedJWT(jwsHeader, innerClaims); signedJWT.sign(new RSASSASigner(signerPrivateKey)); // 3. 外层 JWE 用接收方公钥加密 JWEHeader jweHeader new JWEHeader.Builder(JWEAlgorithm.RSA_OAEP_256, EncryptionMethod.A256GCM) .keyID(enc-key-v1) .contentType(JWT) .build(); JWEObject jweObject new JWEObject(jweHeader, new Payload(signedJWT.serialize())); jweObject.encrypt(new RSAOAEPS256Encrypter(recipientPublicKey)); return jweObject.serialize(); } }注意看步骤 2 和步骤 3 的顺序一定是先签内层再加密外层。如果反过来先加密再签名那签名方等于对一段密文做签名接收方验签之前必须先解密逻辑上没问题但“签名覆盖范围”就不够纯粹而且不利于审计。业内习惯是先签名后加密这样解密之后仍然保有一个独立的验签动作可以在密码学层面把“谁签发”和“给谁看”两个职责分开。3.2 接收端实现解密 验签接收端流程是签发端的逆过程先解析 JWE用接收方私钥解密解出内层 JWT 字符串后再用签发方公钥验签最后校验 Claims 里的 iss、aud、exp 等字段。import com.nimbusds.jose.*; import com.nimbusds.jose.crypto.*; import com.nimbusds.jwt.*; import java.security.interfaces.RSAPrivateKey; import java.security.interfaces.RSAPublicKey; import java.text.ParseException; public class JweTokenReceiver { private final RSAPrivateKey receiverPrivateKey; private final RSAPublicKey issuerPublicKey; public JweTokenReceiver(RSAPrivateKey receiverPrivateKey, RSAPublicKey issuerPublicKey) { this.receiverPrivateKey receiverPrivateKey; this.issuerPublicKey issuerPublicKey; } public JWTClaimsSet parseAndVerify(String compactJwe) throws Exception { // 1. 解析并解密 JWE JWEObject jweObject JWEObject.parse(compactJwe); jweObject.decrypt(new RSAOAEPS256Decrypter(receiverPrivateKey)); // 2. 提取内层 Signed JWT SignedJWT signedJWT jweObject.getPayload().toSignedJWT(); // 3. 验签 if (!signedJWT.verify(new RSASASVerifier(issuerPublicKey))) { throw new SecurityException(JWT signature verification failed); } // 4. 校验 Claims JWTClaimsSet claims signedJWT.getJWTClaimsSet(); if (!system-a.equals(claims.getIssuer())) { throw new SecurityException(unexpected issuer); } if (!claims.getAudience().contains(system-b)) { throw new SecurityException(unexpected audience); } if (claims.getExpirationTime().before(new Date())) { throw new SecurityException(token expired); } return claims; } }有人会问验签和业务数据校验的顺序。我的建议是先验签再查业务字段。因为签名验证是密码学层面的基础检查如果这一步都过不了后面的业务字段再合规也不能信。验签通过之后再检查 iss/aud/exp最后才把 bizData 拿出来做业务处理。3.3 token 续签与 SPA 场景的验证码集成在透传方案里令牌本身时效不能太长但对接方往往希望一个会话能持续 30 分钟甚至更久这时候就需要续签。我做续签一般分两种方式。滑动过期是最简单的一种每次请求验签通过后如果剩余有效期小于某个阈值比如 2 分钟就重新签发一个过期时间为当前时间加 10 分钟的新 JWE 令牌返回给调用方。这种方式适合内部系统间短连接客户端每次拿新令牌替换旧令牌即可但要注意在分布式环境下控制签发频率防止每次请求都触发续签导致令牌满天飞。Refresh Token Rotation 则适合开放平台场景签发短时效的 access token 和一个一次性的 refresh tokenaccess token 过期后用 refresh token 去换新的refresh token 一旦被使用就作废并颁发新值。配合 JWE 外层加密refresh token 也可以做成密文防止在日志里泄露。再说 SPA 项目的验证码集成。前端应用先通过图形验证码或者短信验证码完成“人机验证”后端拿到验证码后校验通过再签发 JWE 令牌返回前端。前端不能像传统 Web 那样依赖 Cookie 自动携带所以一般把令牌存在内存或者 httpOnly 的 Cookie 里每次请求放在 Authorization: Bearer 头。JWE 的好处在这里体现得很明显即使前端存储被 XSS 读取到了令牌攻击者看到的也是一段密文在没有接收方私钥的前提下无法解析出里面的业务数据。注意前端无法验签也无法解密它只负责存储和透传真正的解密验签必须放在后端 B 做。3.4 密钥轮换怎么做密钥轮换是跨系统透传里最容易被忽略、出事时最要命的一环。我见过不少团队上线时用同一个 RSA 密钥跑了一年等要轮换的时候发现没有任何平滑过渡机制只能约一个凌晨窗口整体切换出了事还要回滚。建议从第一天就引入 kid 和 JWKS。签发方和接收方各自维护一个密钥列表每个密钥带 kid、算法、公钥/私钥、生效时间和失效时间。生成 JWE 时用当前生效的 kid接收方解密时读 Header 里的 kid再按 kid 从本地密钥库取对应的私钥。轮换流程就是提前一周把新密钥发布到双方的 JWKS 里但 kid 标记为“待生效”到期后签发方切换到新 kid接收方保留旧密钥一段时间用于解密那些还没过期的老令牌等所有老令牌自然过期后再把旧密钥从密钥库移除。实操里最容易踩的坑是解密时拿不到对方新公钥或者签发方还在用旧私钥签名。排查方法永远是先看两边的 kid 是否一致再看 JWKS 的缓存时间。密钥缓存一般建议做到 60 秒以内别为了性能把公钥缓存一天轮换时全是坑。4. jwt漏洞总结这些坑我基本全踩过4.1 签名类漏洞网上关于 JWT 漏洞的总结很多我结合自己的经历挑重点讲。第一是 algnone 攻击。有些库为了兼容历史版本默认允许算法为 none攻击者把 Header 里的 alg 改成 none删掉 Signature 段服务端如果没校验算法白名单就会直接放行。解决办法很简单验签前先检查 JWSHeader 里的 alg 是否在允许列表比如只允许 RS256/PS256其余一律拒绝。第二是算法混淆攻击。典型场景是服务端原本用 RS256 做验签攻击者把 alg 改成 HS256然后用接收方公钥当 HMAC 密钥来签令牌。如果服务端的验签代码没有区分签名算法用公钥内容去当 HMAC 密钥做 HS256 验证攻击者就能伪装成任意用户。防御思路是验签时明确指定算法并且在密钥管理上区分“验签公钥”和“HMAC 共享密钥”这两种密钥类型不能让同一个密钥在不同算法下具有歧义。第三是 kid 注入。kid 是 Header 里表示密钥 ID 的参数有的实现会直接用 kid 去文件系统读取对应文件攻击者传入 ../../etc/passwd 这样的路径就可能造成任意文件读取。防御思路是 kid 必须严格匹配白名单格式建议用 UUID 或者固定前缀不要直接从 Header 拿原始字符串拼接文件路径。4.2 加密类漏洞JWE 相关的漏洞更多出在算法参数和密钥管理上。一个常见问题是把 JWE 当 JWT 验内层密文直接当明文解析另一个是解密 JWE 时不校验 Authentication Tag 就返回业务数据这等于放弃了完整性保护攻击者可以对密文做位翻转。JWE 的五段结构里最后一段 Tag 就是为了防止密文篡改只要使用 A256GCM 这类 AEAD 算法库会在解密时自动校验 Tag但是如果你的代码为了性能特意跳过校验那就是给自己埋雷。还有一类问题是算法降级。JWEHeader 里的 alg 可以从 RSA-OAEP-256 被替换成 RSA1_5因为 RSA1_5 存在历史漏洞老库可能还支持。所以接收端解密前同样要做算法白名单校验只接受 RSA_OAEP_256 或者 ECDH_ES其他一律拒绝。4.3 业务层漏洞业务层的 JWT 漏洞通常不是密码学问题而是代码逻辑问题。最典型的是过期时间服务端不校验。很多团队在网关层已经验过 exp到了业务服务就默认“已经验过了”结果某个内部接口被直接调用时绕过了网关业务服务又不查 exp令牌过期了照样能用。其次是 jti 不落库导致重放攻击。JWT 的 jti 字段本意就是防重放但很多人只把它当 UUID 生成生成完就忘了存。正确做法是接收方把用过的 jti 存在 Redis 里设置过期时间跟令牌有效期一致重复出现直接拒绝。再者是 Claims 里的敏感信息没脱敏。即使外层做了 JWE内层 JWT 是密文没错但你要考虑日志输出的时候会不会顺手把整个 JWE 串打出来。JWE 本身不怕被看到因为看不到明文但如果内层 JWT 的签名密钥泄露攻击者可以伪造签名串然后用自己的公钥加密接收方验签就直接失败。所以密钥管理依然是第一优先级。5. 常见问题与排查技巧实录5.1 问题速查表我把实际运维中碰到的问题整理成一张速查表遇到相同症状可以直接对照。现象可能原因排查手段接收方解密报 InvalidKeyException签发方用了接收方公钥加密但接收方私钥与公钥不匹配对比两端 JWKS 里的 kid 和密钥模数解出来的 JWT 验签失败签发方签名私钥与接收方保存的验签公钥不一致检查签发方 JWSHeader 里的 kid确认接收方存的是对应公钥令牌能解密但业务数据为空内层 Claims 里没有 bizData或序列化时字段名不一致先解出内层 JWT打印 Claims 结构偶尔有令牌验签失败签发方可能有多台机器其中一台还在用旧签名私钥检查签发方密钥发布流程确认新旧密钥切换完成请求响应慢JWE 解密和 JWT 验签都是非对称运算考虑 PS256 做签名允许批量验签或者加密内容用 ECDH-ES 协商会话密钥日志里出现大量 JWE 串拦截器或日志切面打印了 Authorization 头对 Authorization 头做脱敏只保留前 20 位后 20 位5.2 排查心法跨系统透传的问题最让人头疼的往往是“两边都觉得自己的代码没问题”。我的排查习惯是先用在线 JWT 调试工具把外层 JWE 解密成内层 JWT看 Header 里的 alg/kid/cty 到底长什么样再用 tcpdump 或者代理抓一次真实请求对比签发端和接收端看到的令牌是否完全一致。很多时候问题出在某个网关对 Header 做了大小写转换或者对 URL 做了重编码导致整个 JWE 串被改动接收端解析时直接崩溃。另一个技巧是给 JWE 串里的每一段都做 Base64URL 解码验证。JWE 五段分别是 Header、Encrypted Key、IV、Ciphertext、Tag如果某一段长度明显不对比如 Tag 不是 16 字节基本可以确定是加密算法参数不一致。A256GCM 的 Tag 一定是 16 字节IV 是 12 字节看到 IV 是 16 字节就该怀疑对方用的是 AES-CBC 而不是 GCM。5.3 性能调优与超时控制JWE 加密解密涉及非对称计算RSA-2048 一次加密在普通服务器上大概是 1 到 3 毫秒验签再花 1 到 2 毫秒单次透传多出 5 毫秒左右对绝大多数业务可以接受。但如果每秒几千的调用量非对称计算会明显增加 CPU 开销。我的优化思路是内层 JWT 签名优先用 ES256 或者 PS256ES256 的密钥短、计算快PS256 支持批量验签外层加密在密钥协商类算法里优先考虑 ECDH-ESECDH 比 RSA 快得多但需要双方预先交换椭圆曲线公钥。超时控制也要设计到位。签发端和接收端对时钟偏差敏感建议接收端校验 exp 时容忍 30 秒的时钟偏差。分布式环境下机器时钟不同步是常态严格按毫秒校验会导致线上大量令牌“提前过期”。我用过的最实用的方案是把服务统一走 NTP 对时同时在验签逻辑里加一个最大 60 秒的 leeway既保证了实效性又兼顾了工程容错。最后再分享两个小技巧一个是我实际落地后养成的习惯把所有 JWE 令牌统一走独立的透传接口不让它混在普通业务接口里。这样日志脱敏、限流、审计都比较干净。另一个是上线前一定要做一次“故障演练”——故意用旧密钥签一个令牌发给接收方确认接收方能明确报出“kid not found”或者“signature verification failed”而不是默默吞掉异常返回成功。很多方案看着没问题恰恰是异常分支处理得太“优雅”导致真正出问题时连个像样的报错都看不到。如果你正在设计跨系统数据透传方案我的建议是别一上来就堆技术先跟对接方确认三件事密钥轮换由谁主导、日志里能否打印完整令牌、异常时返回什么错误码。这三件事定了后面写代码就很顺。JWT/JWE 这套组合不是银弹但它确实是跨系统敏感数据透传场景下标准化程度最高、踩坑最少的一条路。
先说我为什么会对这个题目感兴趣。最近在做一个跨系统的数据对接项目业务方提了一个很硬的要求所有跨系统调用里涉及的敏感字段不管走内网还是公网都不能在任何一个中间环节出现明文同时接收方必须能验证数据确实来自合法来源且没有被篡改。这个需求听起来不复杂真正落地时要同时解决四个问题身份可信、数据机密、防重放、密钥可轮换。我最终的选型就是基于 JWT/JWE 的跨系统安全数据透传方案——用 JWT 承载身份与数据的可信性用 JWE 解决敏感载荷的机密性两者嵌套组成一个完整的透传令牌。这篇文章适合正在做系统集成、微服务间数据交换、开放平台接口对接的后端和运维同学参考也适合安全工程师做方案评审时当一份现成的踩坑清单。1. 为什么跨系统透传需要 JWT/JWE 这套组合1.1 透传场景里的三个典型痛点我先把问题还原一下。所谓“跨系统数据透传”最常见的形式就是系统 A 拿到一份数据原封不动或者稍作处理后传给系统 B、系统 C。最原始的方案是 A 把数据 POST 给 BB 存库C 再来拉。但随着系统多了你会发现三个痛点特别明显。第一个痛点是“数据在链路上裸奔”。很多企业内网默认是可信的结果一份包含手机号、身份证号、银行卡号的 JSON 就明文躺在消息队列或者接口日志里。运维查问题方便了安全审计来的时候大家都不好看。第二个痛点是“接收方无法证明数据来源”。A 传了一份订单给 BB 怎么知道这份订单真是 A 生成的而不是某个内部人员手工构造的假请求光靠内网 IP 白名单说实话约等于没有。第三个痛点是“中间环节不可控”。数据可能会经过网关、缓存、消息中间件、日志采集器任何一个环节都可能有意无意地读到业务字段。这时候你就需要一种机制中间的管道只负责搬运搬的是什么完全看不懂只有最终接收方能解开。这三个痛点叠加起来纯 HTTPS 解决不了。HTTPS 保证的是“客户端和服务端之间这条链路不泄露”但数据一旦进了服务端在日志里、在缓存里、在下一个内部调用里它仍然是明文。所以你需要的是一个“端到端加密 来源认证”的载体而 JWT/JWE 嵌套结构正好是干这个的。1.2 JWT 与 JWE 的分工签名保证可信加密保证机密很多人一开始会混淆 JWT 和 JWE其实这两者解决的问题完全不同。JWT 全称是 JSON Web Token它本身默认是一段 Base64URL 编码的 JSON包含 Header、Payload、Signature 三段。JWT 的核心价值是签名用 HMAC 或者 RSA/ECDSA 对 Header 和 Payload 做摘要接收方验证签名就能确认数据没被改过并且确实来自持有对应密钥的一方。但注意JWT 默认是“不加密”的Payload 里那串 Base64URL 一解码就是明文所以 JWT 适合放“不敏感但需要防篡改”的信息比如用户 ID、角色、过期时间。JWE 全称是 JSON Web Encryption它才是真正做机密性的。JWE 同样是一串 Base64URL 拼接的 Compact 串但结构变成了五段Header、Encrypted Key、Initialization Vector、Ciphertext、Authentication Tag。它把真正的业务数据加密成密文并且附带完整性校验接收方用私钥或者对称密钥解出来才能看到内容。我最终的方案是“先签后加密”内层先构造一个带签名的 JWT里面放业务数据外层再用 JWE 把整个 JWT 串加密。这样接收方拿到令牌后先解 JWE 得到内层 JWT再验 JWT 签名。加密保证传输和存储环节没人能看到明文签名保证解密之后的内容确实来自可信签发方。这两层互为补充缺一个都不完整。1.3 为什么不是我直接用 HTTPS 自定义加密有人会问我直接用 HTTPS然后在 Body 里自定义一个 AES 加密字段不就行了当然可以很多老系统就是这么干的。但问题在于自定义加密没有标准每个团队写出来的都不一样后续维护就是灾难。A 系统用 AES/ECB/PKCS5PaddingB 系统用 AES/GCMC 系统在密钥里拼接了一个固定盐D 系统直接在代码里写死密钥安全评审的时候我看过太多这种代码血压容易高。JWE 的好处是这套加密流程是标准化的算法标识、密钥管理方式、加密模式、完整性校验都有 RFC 规范不同语言、不同框架之间可以互认。比如 Java 的 nimbus-jose-jwt、Node 的 jose 库、Go 的 go-jose实现的是同一套标准A 系统发出的 JWEB 系统一定能解前提是密钥配对正确。跨团队、跨语言、跨系统这比自研加密方案靠谱得多。2. 核心设计先验签后解密的双层令牌结构2.1 一个透传令牌应该长什么样我先给出一份可以直接落地的令牌结构设计。内层 JWT 的 Claims 建议这样规划Claims 字段含义是否必填说明iss签发方标识是比如 system-a接收方用它做来源白名单判断sub数据主体标识是比如 userId 或订单号便于接收方关联业务aud接收方标识是防止令牌被拿到其他系统重放exp过期时间是建议 5 到 15 分钟透传场景不需要长时效iat签发时间是配合 exp 做时效校验jti令牌唯一 ID是用于防重放记录接收方落库去重bizData业务载荷否放真正要透传的数据建议限制大小nonce随机数是增加密文随机性防止相同数据产生相同密文外层 JWE Header 我通常会加两个自定义参数kid 表示解密密钥版本cty 固定为 JWT 表示内层是 JWT。这样接收方拿到令牌后第一件事就是读 kid 找到对应的解密私钥解完再按 iss 找到签发方公钥验签流程非常清晰。2.2 JOSE Header 参数怎么选选算法的时候我建议遵循一个原则能用现代算法就不要迁就老系统。内层签名算法对称场景最简单的是 HS256但 HS256 要求签发方和接收方共享同一个 HMAC 密钥跨系统一旦有一方泄露密钥所有系统全部沦陷所以我更推荐 RS256 或 PS256用非对称密钥对签发方持有私钥接收方只保存公钥验签。如果性能敏感并且双方都在自己的可信域内也可以考虑 EdDSA但兼容性需要考虑。外层加密算法我推荐 RSA-OAEP-256 做密钥封装A256GCM 做内容加密。RSA-OAEP-256 是 RSA-OAEP 的一种参数组合比老旧的 RSA1_5 安全得多A256GCM 是 AES-GCM 模式自带完整性校验密文长度等于明文长度加上 16 字节的认证标签不会膨胀太多。如果你对性能要求极高也可以直接用 ECDH-ES 做密钥协商但那要求接收方预先提供椭圆曲线公钥集成成本会高一些。2.3 密钥体系与算法选型表我把常见的算法组合整理成一张表方便你做选型用途推荐算法场景说明密钥管理方式内层签名RS256/PS256签发方私钥签名接收方公钥验签签发方保管私钥接收方存公钥外层加密RSA-OAEP-256 A256GCM接收方公钥加密接收方私钥解密接收方保管私钥签发方存接收方公钥对称备选HS256 A256CBC-HS512跨系统数量少且双方可控双方共享密钥建议通过密钥管理系统轮换异步高性能EdDSA ECDH-ES高并发、极低延迟密钥协商对需要双方预先交换公钥这里有个容易忽略的点在跨系统透传方案里签发方和接收方的密钥诉求是不对称的。签发方需要“自己的私钥”来签 JWT同时需要“接收方的公钥”来加密 JWE接收方需要“自己的私钥”来解 JWE同时需要“签发方的公钥”来验签。所以密钥交换是双向的别只给对面一个公钥就完事那会导致后期解密验签全失败。3. 实操签发、透传、接收全链路实现3.1 签发端实现JWE 加密我用 Java 的 nimbus-jose-jwt 库来演示因为这个库在 JOSE 标准覆盖度和社区活跃度上都比较稳。签发端要做两件事先构造并签名内层 JWT再用接收方公钥加密成 JWE。import com.nimbusds.jose.*; import com.nimbusds.jose.crypto.*; import com.nimbusds.jwt.*; import java.security.interfaces.RSAPrivateKey; import java.security.interfaces.RSAPublicKey; import java.util.Date; import java.util.UUID; public class JweTokenIssuer { private final RSAPrivateKey signerPrivateKey; private final RSAPublicKey recipientPublicKey; public JweTokenIssuer(RSAPrivateKey signerPrivateKey, RSAPublicKey recipientPublicKey) { this.signerPrivateKey signerPrivateKey; this.recipientPublicKey recipientPublicKey; } public String issueToken(String subject, String audience, String bizData) throws JOSEException { // 1. 构建内层 JWT Claims long now System.currentTimeMillis(); JWTClaimsSet innerClaims new JWTClaimsSet.Builder() .issuer(system-a) .subject(subject) .audience(audience) .expirationTime(new Date(now 10 * 60 * 1000)) .issueTime(new Date(now)) .jwtID(UUID.randomUUID().toString()) .claim(bizData, bizData) .claim(nonce, UUID.randomUUID().toString()) .build(); // 2. 内层 JWT 用 RSA 私钥签名 JWSHeader jwsHeader new JWSHeader.Builder(JWSAlgorithm.RS256) .keyID(sign-key-v1) .build(); SignedJWT signedJWT new SignedJWT(jwsHeader, innerClaims); signedJWT.sign(new RSASSASigner(signerPrivateKey)); // 3. 外层 JWE 用接收方公钥加密 JWEHeader jweHeader new JWEHeader.Builder(JWEAlgorithm.RSA_OAEP_256, EncryptionMethod.A256GCM) .keyID(enc-key-v1) .contentType(JWT) .build(); JWEObject jweObject new JWEObject(jweHeader, new Payload(signedJWT.serialize())); jweObject.encrypt(new RSAOAEPS256Encrypter(recipientPublicKey)); return jweObject.serialize(); } }注意看步骤 2 和步骤 3 的顺序一定是先签内层再加密外层。如果反过来先加密再签名那签名方等于对一段密文做签名接收方验签之前必须先解密逻辑上没问题但“签名覆盖范围”就不够纯粹而且不利于审计。业内习惯是先签名后加密这样解密之后仍然保有一个独立的验签动作可以在密码学层面把“谁签发”和“给谁看”两个职责分开。3.2 接收端实现解密 验签接收端流程是签发端的逆过程先解析 JWE用接收方私钥解密解出内层 JWT 字符串后再用签发方公钥验签最后校验 Claims 里的 iss、aud、exp 等字段。import com.nimbusds.jose.*; import com.nimbusds.jose.crypto.*; import com.nimbusds.jwt.*; import java.security.interfaces.RSAPrivateKey; import java.security.interfaces.RSAPublicKey; import java.text.ParseException; public class JweTokenReceiver { private final RSAPrivateKey receiverPrivateKey; private final RSAPublicKey issuerPublicKey; public JweTokenReceiver(RSAPrivateKey receiverPrivateKey, RSAPublicKey issuerPublicKey) { this.receiverPrivateKey receiverPrivateKey; this.issuerPublicKey issuerPublicKey; } public JWTClaimsSet parseAndVerify(String compactJwe) throws Exception { // 1. 解析并解密 JWE JWEObject jweObject JWEObject.parse(compactJwe); jweObject.decrypt(new RSAOAEPS256Decrypter(receiverPrivateKey)); // 2. 提取内层 Signed JWT SignedJWT signedJWT jweObject.getPayload().toSignedJWT(); // 3. 验签 if (!signedJWT.verify(new RSASASVerifier(issuerPublicKey))) { throw new SecurityException(JWT signature verification failed); } // 4. 校验 Claims JWTClaimsSet claims signedJWT.getJWTClaimsSet(); if (!system-a.equals(claims.getIssuer())) { throw new SecurityException(unexpected issuer); } if (!claims.getAudience().contains(system-b)) { throw new SecurityException(unexpected audience); } if (claims.getExpirationTime().before(new Date())) { throw new SecurityException(token expired); } return claims; } }有人会问验签和业务数据校验的顺序。我的建议是先验签再查业务字段。因为签名验证是密码学层面的基础检查如果这一步都过不了后面的业务字段再合规也不能信。验签通过之后再检查 iss/aud/exp最后才把 bizData 拿出来做业务处理。3.3 token 续签与 SPA 场景的验证码集成在透传方案里令牌本身时效不能太长但对接方往往希望一个会话能持续 30 分钟甚至更久这时候就需要续签。我做续签一般分两种方式。滑动过期是最简单的一种每次请求验签通过后如果剩余有效期小于某个阈值比如 2 分钟就重新签发一个过期时间为当前时间加 10 分钟的新 JWE 令牌返回给调用方。这种方式适合内部系统间短连接客户端每次拿新令牌替换旧令牌即可但要注意在分布式环境下控制签发频率防止每次请求都触发续签导致令牌满天飞。Refresh Token Rotation 则适合开放平台场景签发短时效的 access token 和一个一次性的 refresh tokenaccess token 过期后用 refresh token 去换新的refresh token 一旦被使用就作废并颁发新值。配合 JWE 外层加密refresh token 也可以做成密文防止在日志里泄露。再说 SPA 项目的验证码集成。前端应用先通过图形验证码或者短信验证码完成“人机验证”后端拿到验证码后校验通过再签发 JWE 令牌返回前端。前端不能像传统 Web 那样依赖 Cookie 自动携带所以一般把令牌存在内存或者 httpOnly 的 Cookie 里每次请求放在 Authorization: Bearer 头。JWE 的好处在这里体现得很明显即使前端存储被 XSS 读取到了令牌攻击者看到的也是一段密文在没有接收方私钥的前提下无法解析出里面的业务数据。注意前端无法验签也无法解密它只负责存储和透传真正的解密验签必须放在后端 B 做。3.4 密钥轮换怎么做密钥轮换是跨系统透传里最容易被忽略、出事时最要命的一环。我见过不少团队上线时用同一个 RSA 密钥跑了一年等要轮换的时候发现没有任何平滑过渡机制只能约一个凌晨窗口整体切换出了事还要回滚。建议从第一天就引入 kid 和 JWKS。签发方和接收方各自维护一个密钥列表每个密钥带 kid、算法、公钥/私钥、生效时间和失效时间。生成 JWE 时用当前生效的 kid接收方解密时读 Header 里的 kid再按 kid 从本地密钥库取对应的私钥。轮换流程就是提前一周把新密钥发布到双方的 JWKS 里但 kid 标记为“待生效”到期后签发方切换到新 kid接收方保留旧密钥一段时间用于解密那些还没过期的老令牌等所有老令牌自然过期后再把旧密钥从密钥库移除。实操里最容易踩的坑是解密时拿不到对方新公钥或者签发方还在用旧私钥签名。排查方法永远是先看两边的 kid 是否一致再看 JWKS 的缓存时间。密钥缓存一般建议做到 60 秒以内别为了性能把公钥缓存一天轮换时全是坑。4. jwt漏洞总结这些坑我基本全踩过4.1 签名类漏洞网上关于 JWT 漏洞的总结很多我结合自己的经历挑重点讲。第一是 algnone 攻击。有些库为了兼容历史版本默认允许算法为 none攻击者把 Header 里的 alg 改成 none删掉 Signature 段服务端如果没校验算法白名单就会直接放行。解决办法很简单验签前先检查 JWSHeader 里的 alg 是否在允许列表比如只允许 RS256/PS256其余一律拒绝。第二是算法混淆攻击。典型场景是服务端原本用 RS256 做验签攻击者把 alg 改成 HS256然后用接收方公钥当 HMAC 密钥来签令牌。如果服务端的验签代码没有区分签名算法用公钥内容去当 HMAC 密钥做 HS256 验证攻击者就能伪装成任意用户。防御思路是验签时明确指定算法并且在密钥管理上区分“验签公钥”和“HMAC 共享密钥”这两种密钥类型不能让同一个密钥在不同算法下具有歧义。第三是 kid 注入。kid 是 Header 里表示密钥 ID 的参数有的实现会直接用 kid 去文件系统读取对应文件攻击者传入 ../../etc/passwd 这样的路径就可能造成任意文件读取。防御思路是 kid 必须严格匹配白名单格式建议用 UUID 或者固定前缀不要直接从 Header 拿原始字符串拼接文件路径。4.2 加密类漏洞JWE 相关的漏洞更多出在算法参数和密钥管理上。一个常见问题是把 JWE 当 JWT 验内层密文直接当明文解析另一个是解密 JWE 时不校验 Authentication Tag 就返回业务数据这等于放弃了完整性保护攻击者可以对密文做位翻转。JWE 的五段结构里最后一段 Tag 就是为了防止密文篡改只要使用 A256GCM 这类 AEAD 算法库会在解密时自动校验 Tag但是如果你的代码为了性能特意跳过校验那就是给自己埋雷。还有一类问题是算法降级。JWEHeader 里的 alg 可以从 RSA-OAEP-256 被替换成 RSA1_5因为 RSA1_5 存在历史漏洞老库可能还支持。所以接收端解密前同样要做算法白名单校验只接受 RSA_OAEP_256 或者 ECDH_ES其他一律拒绝。4.3 业务层漏洞业务层的 JWT 漏洞通常不是密码学问题而是代码逻辑问题。最典型的是过期时间服务端不校验。很多团队在网关层已经验过 exp到了业务服务就默认“已经验过了”结果某个内部接口被直接调用时绕过了网关业务服务又不查 exp令牌过期了照样能用。其次是 jti 不落库导致重放攻击。JWT 的 jti 字段本意就是防重放但很多人只把它当 UUID 生成生成完就忘了存。正确做法是接收方把用过的 jti 存在 Redis 里设置过期时间跟令牌有效期一致重复出现直接拒绝。再者是 Claims 里的敏感信息没脱敏。即使外层做了 JWE内层 JWT 是密文没错但你要考虑日志输出的时候会不会顺手把整个 JWE 串打出来。JWE 本身不怕被看到因为看不到明文但如果内层 JWT 的签名密钥泄露攻击者可以伪造签名串然后用自己的公钥加密接收方验签就直接失败。所以密钥管理依然是第一优先级。5. 常见问题与排查技巧实录5.1 问题速查表我把实际运维中碰到的问题整理成一张速查表遇到相同症状可以直接对照。现象可能原因排查手段接收方解密报 InvalidKeyException签发方用了接收方公钥加密但接收方私钥与公钥不匹配对比两端 JWKS 里的 kid 和密钥模数解出来的 JWT 验签失败签发方签名私钥与接收方保存的验签公钥不一致检查签发方 JWSHeader 里的 kid确认接收方存的是对应公钥令牌能解密但业务数据为空内层 Claims 里没有 bizData或序列化时字段名不一致先解出内层 JWT打印 Claims 结构偶尔有令牌验签失败签发方可能有多台机器其中一台还在用旧签名私钥检查签发方密钥发布流程确认新旧密钥切换完成请求响应慢JWE 解密和 JWT 验签都是非对称运算考虑 PS256 做签名允许批量验签或者加密内容用 ECDH-ES 协商会话密钥日志里出现大量 JWE 串拦截器或日志切面打印了 Authorization 头对 Authorization 头做脱敏只保留前 20 位后 20 位5.2 排查心法跨系统透传的问题最让人头疼的往往是“两边都觉得自己的代码没问题”。我的排查习惯是先用在线 JWT 调试工具把外层 JWE 解密成内层 JWT看 Header 里的 alg/kid/cty 到底长什么样再用 tcpdump 或者代理抓一次真实请求对比签发端和接收端看到的令牌是否完全一致。很多时候问题出在某个网关对 Header 做了大小写转换或者对 URL 做了重编码导致整个 JWE 串被改动接收端解析时直接崩溃。另一个技巧是给 JWE 串里的每一段都做 Base64URL 解码验证。JWE 五段分别是 Header、Encrypted Key、IV、Ciphertext、Tag如果某一段长度明显不对比如 Tag 不是 16 字节基本可以确定是加密算法参数不一致。A256GCM 的 Tag 一定是 16 字节IV 是 12 字节看到 IV 是 16 字节就该怀疑对方用的是 AES-CBC 而不是 GCM。5.3 性能调优与超时控制JWE 加密解密涉及非对称计算RSA-2048 一次加密在普通服务器上大概是 1 到 3 毫秒验签再花 1 到 2 毫秒单次透传多出 5 毫秒左右对绝大多数业务可以接受。但如果每秒几千的调用量非对称计算会明显增加 CPU 开销。我的优化思路是内层 JWT 签名优先用 ES256 或者 PS256ES256 的密钥短、计算快PS256 支持批量验签外层加密在密钥协商类算法里优先考虑 ECDH-ESECDH 比 RSA 快得多但需要双方预先交换椭圆曲线公钥。超时控制也要设计到位。签发端和接收端对时钟偏差敏感建议接收端校验 exp 时容忍 30 秒的时钟偏差。分布式环境下机器时钟不同步是常态严格按毫秒校验会导致线上大量令牌“提前过期”。我用过的最实用的方案是把服务统一走 NTP 对时同时在验签逻辑里加一个最大 60 秒的 leeway既保证了实效性又兼顾了工程容错。最后再分享两个小技巧一个是我实际落地后养成的习惯把所有 JWE 令牌统一走独立的透传接口不让它混在普通业务接口里。这样日志脱敏、限流、审计都比较干净。另一个是上线前一定要做一次“故障演练”——故意用旧密钥签一个令牌发给接收方确认接收方能明确报出“kid not found”或者“signature verification failed”而不是默默吞掉异常返回成功。很多方案看着没问题恰恰是异常分支处理得太“优雅”导致真正出问题时连个像样的报错都看不到。如果你正在设计跨系统数据透传方案我的建议是别一上来就堆技术先跟对接方确认三件事密钥轮换由谁主导、日志里能否打印完整令牌、异常时返回什么错误码。这三件事定了后面写代码就很顺。JWT/JWE 这套组合不是银弹但它确实是跨系统敏感数据透传场景下标准化程度最高、踩坑最少的一条路。
