验证使用 JSON Web 加密 (JWE) 加密的安全令牌的颁发者？答案

【问题标题】：Validating issuer of a security token encrypted with JSON Web Encryption (JWE)?验证使用 JSON Web 加密 (JWE) 加密的安全令牌的颁发者？
【发布时间】：2013-03-08 01:09:38
【问题描述】：

我一直在阅读带有 latest draft being 08 的 JSON Web 加密 (JWE) 规范，因为我们正在考虑在我们的身份验证服务器中支持 JSON Web 令牌 (JWT)。

使用它定义的非对称加密方法，对称密钥（内容主密钥）使用收件人公钥进行加密。这是有道理的，只有收件人才能解密它，并确保令牌是为他们准备的。

通常我还希望看到一些东西可以证明令牌是谁来自，例如使用发行人的私钥创建的签名，可以使用他们的公钥进行验证。但是，签名似乎也来自内容主密钥或接收者的公钥，没有提及颁发者的私钥。

如果没有这个，在我看来——只要知道预期的令牌格式——任何拥有接收者公钥的人（即任何人）都可以生成一个有效的令牌；不仅仅是受信任的身份验证服务器。

我不是密码学专家（远非如此），所以我确定我在这里遗漏了一些东西。接收方如何验证非对称加密令牌是否来自受信任的发行者？

鉴于 JSON Web 签名 (JWS) 规范确实定义了使用颁发者的私钥并且可以使用他们的公钥进行验证的签名，我想知道这个想法是否是JWE 令牌应该是 JWS 令牌吗？

【问题讨论】：

标签： security encryption jwt jwe

【解决方案1】：

JWT 当然允许嵌套有效负载。事实上，规范中有一个specific reference，其中cty（内容类型）标头参数可以设置为JWT，以指示有效负载实际上是另一个JWT。

因此，您很可能会创建一个 JWE 并将其包装在一个 JWS 中，并使用您的私钥签名。这似乎也是 JOSE 邮件列表中this thread 的结论（或至少一种解决方案）。还有另一个related thread 是关于减少有效负载大小的。一般来说，该邮件列表可能值得关注，因为它是规范背后的人常去的地方。

【讨论】：

酷，感谢您的参考。在更仔细地重新阅读规范时，第 10 节似乎也涵盖了这一点，并提供了一些额外的指导：“虽然在语法上，嵌套 JWT 的签名和加密操作可以按任何顺序应用，通常发件人应该签署消息并然后对结果进行加密（从而加密签名）。这可以防止剥离签名的攻击，只留下加密的消息，并为签名者提供隐私。此外，在许多司法管辖区，加密文本上的签名被认为是无效的。 "
是的，我想这是有道理的，因为加密的消息本身是通过 GCM 或 encrypt-then-HMAC 方案进行完整性保护的。这也与 Mike Jones 在邮件列表中的建议相反。在实现这些东西时总是有很大的空间可以在某个地方滑倒:)。
我需要解密 JWE 并提取 JAVA 中的声明集。有没有这样的图书馆？
最好先签名再加密。使用此顺序，签名和内容被加密。如果您签署 JWE，则可以删除或替换签名，并且可以识别签名的颁发者。
这在一定程度上取决于上下文。如果你这样做了，那么类似地，接收者可以解密令牌并将其重新加密给另一方，使其看起来像是发行者/签名者将消息发送给他们(surreptitious forwarding)。如果 JWT 同时包含 iss 和 aud 声明，则接收者可以检查它是目标受众，并且发行者是签名者。