为什么使用AES_128_CBC_HMAC_SHA_256加密JWT会修改alg头参数？

你遇到的所有问题核心是混淆了 JWS（签名型JWT） 和 JWE（加密型JWT） 两种不同的JWT规范结构，具体对应疑问的解答如下：

1. 为什么alg参数会被修改 #

• 你最初生成的是签名JWT（JWS），头部alg字段的含义是「签名使用的算法」，所以取值为HS256符合预期。
• 当你触发加密操作时，Microsoft.IdentityModel库默认会直接生成加密JWT（JWE）结构，而非你理解的「把已生成的JWS整体加密后套一层JWT外壳」。JWE头部的alg字段含义已经变成了「内容加密密钥的包装/协商算法」，你使用的AES_128_CBC_HMAC_SHA_256加密方案对应的标准密钥包装算法就是A128KW，所以alg被自动修改是完全符合JWE规范的行为。

2. 你对签名+加密流程的理解偏差 #

你认知的「先签名、再把payload+签名整体加密」是嵌套JWT的实现逻辑，属于可选的组合方案，不是JWE的默认生成逻辑：

• 标准JWE结构本身只有加密层，内置了完整性校验能力，不需要额外做签名操作，所以不会保留你之前配置的HS256签名相关参数。
• 如果你需要同时实现「防篡改签名+防泄露加密」的双重能力，必须手动走嵌套流程：
  • 第一步：先生成内层JWS，指定alg=HS256做签名，得到完整的[JWS头部].[JWS payload].[JWS签名]字符串
  • 第二步：把上述完整JWS字符串作为外层JWE的明文payload，配置加密算法为A128CBC-HS256生成最终令牌
    这种场景下接收方解密外层JWE后，就能从内层JWS的头部读取到HS256的签名算法，再完成验签即可。

3. 加密后仍然存在.的原因 #

JWE的标准结构本身就是5段.分隔的格式：[JWE头部].[加密后的内容加密密钥].[初始化向量].[加密后的明文].[认证标签]，你看到的.是JWE本身的结构分隔符，不是内层JWS的分隔符，属于正常现象。

4. 关于Microsoft.IdentityModel库的说明 #

这个库没有内置自动嵌套JWT的逻辑，如果你同时开启签名和加密参数，库会默认使用JWE的内置完整性校验代替你配置的HS256签名，不会生成嵌套结构。如果需要嵌套效果，必须手动实现上述两步生成流程。

内容的提问来源于stack exchange，提问作者Beltway