JJWT项目安全升级：不再支持非none算法的未签名JWT解析

在JJWT库从0.11.5版本升级到0.12.3版本的过程中，一个重要的安全变更引起了开发者注意：库不再支持解析带有非none算法声明但实际未签名的JWT令牌。这一变更反映了JWT规范的最新安全要求，也标志着JJWT在安全性方面的进一步强化。

背景与变更内容

在旧版JJWT中，开发者可以解析格式为"xxxx.yyyy"的JWT（即去掉签名部分的令牌），即使其头部声明的算法不是"none"。这种用法在某些特殊场景下被采用，例如当系统需要临时绕过签名验证时。

然而，从0.12.3版本开始，JJWT严格执行RFC 7518规范的第8.5节要求：只有明确声明算法为"none"的JWT才能被作为未签名令牌解析。如果尝试解析带有其他算法声明（如ES256、RS256等）但缺少签名部分的JWT，将会抛出UnsupportedJwtException异常。

安全考量与技术原理

这一变更背后有着深刻的安全考量：

1. 规范合规性：JWT规范明确要求，任何声明了签名算法但实际上未包含签名的令牌都应被视为无效。这是为了防止潜在的令牌篡改攻击。

2. 安全边界清晰：强制要求显式声明"none"算法，使得系统的安全边界更加明确。开发者无法意外地忽略签名验证，必须明确选择不验证签名。

3. 防止中间人攻击：如果允许去掉签名部分后仍然解析令牌，攻击者可能截获有效JWS后去掉签名，使系统接受未经验证的内容。

迁移方案与最佳实践

对于确实需要处理未签名JWT的场景，推荐以下做法：

1. 显式声明none算法：确保JWT头部明确包含"alg":"none"声明。这是规范认可的唯一合法未签名JWT形式。

2. 令牌转换模式：如果必须处理来自第三方的签名JWT，建议先完整验证其签名，然后生成一个新的未签名JWT（带有none算法声明）供内部使用。

3. 安全警告：任何使用未签名JWT的方案都应谨慎评估，因为这意味着放弃了JWT最重要的安全特性——防篡改。

技术实现细节

新版JJWT通过以下机制实现这一安全要求：

1. 算法声明检查：在解析未签名JWT时，会严格检查头部alg字段是否为"none"。

2. 签名存在性验证：对于声明了签名算法的JWT，必须包含完整的签名部分（即三段式结构）。

3. 明确的API设计：通过unsecured()方法链明确标识出"不验证签名"的解析意图，避免隐式行为。

这一变更虽然可能导致部分现有代码需要调整，但从长远看有助于构建更安全的JWT处理系统，也使得JJWT的行为更加符合行业标准和最佳实践。开发者在升级时应评估现有实现，确保符合新的安全要求。