JSON Web令牌标准已经在IETF和OIDF上收到了许多安全审查，专家认为它足够安全。但这并不是万无一失的。作为开发人员，如果不适当地使用JWT或实现JWT的库(包括这个库)，就很容易搬起石头砸自己的脚。

1. 永远不要让JWT头单独驱动验证

收到的JWTs必须经过适当的验证。当您这样做时，永远不要让JWT或它的任何头参数单独驱动验证过程。始终有一个明确的合同，适合您的应用程序，规定了允许的JWT算法和其他头部或负载参数。

在此初始筛选成功通过之前，不要尝试加密处理JWT。如果您收到一个JWT，其中包含一个未预料到的算法，那么丢弃它，并立即停止。

请记住，JWTs可以作为HMAC受保护的、签名的、加密的，甚至完全不安全的(alg = none)。JWT解析并具有正确的格式并不意味着它是可信的。让你的应用程序容易受到攻击的最明显的方法是获取alg头部，然后立即验证JWT的HMAC或签名，而不是首先检查JWT alg是否可以接受。如果你的应用程序得到一个不安全的JWT与alg = none会发生什么?

所以请记住，一定要有一个明确的合同，并使用它来筛选每个JWT之前，试图解密它，或检查其签名或HMAC。

例如，OpenID连接客户端在注册时建立允许的ID令牌安全算法。不匹配预期算法的ID令牌将被立即丢弃。

示例ID令牌契约:

{ "id_token_signed_response_alg" : "RS256",

"id_token_encrypted_response_alg" : "RSA-OAEP",

"id_token_encrypted_response_enc" : "A128GCM"

}

OpenID Connect进一步指定验证ID令牌的RSA或EC密钥来自何处:这是IdP发布的JWK集合URL，而不是其他地方。如果多个密钥在JWK集合URL上发布，那么应该使用哪个密钥?这是通过JWT的kid (key ID)头参数进行通信的。

{ "alg" : "RS256",

"kid" : "sho0jea6" }

如果要验证ID令牌，请使用经过良好测试和建立的库，比如Pac4j。是的，我们确实维护了一个全面的OpenID Connect SDK，但是我们建议您使用更高级别的Pac4j，因为它提供了一个更适合开发人员的包。

如果要将JWTs验证为OAuth 2.0访问令牌，请查看这里的示例。它演示了Nimbus JOSE+JWT框架在处理JWTs时的用法，该框架考虑了上述所有因素。

2. 知道这个算法

了解您的算法，以及在完整性、真实性、不可抵赖性和机密性方面，您可以期望它们具有哪些安全性属性。

常见的错误是将基于哈希的消息验证码(HMAC)等同于数字签名。不，它们是不一样的，即使它们使用一种公共格式(JSON Web签名)。请记住，JWS格式也用于不安全的JWTs (alg = none)。

这个库不允许您将不安全的JWTs与HMAC或数字签名保护的JWTs混淆，因为它使用了单独的Java类型。但其他库可能不会强制执行此功能。我们发现OOP和类型安全通常对安全性有好处。

如果您想知道您的应用程序使用哪种特定的JWS或JWE算法，请查看我们的算法选择指南。

3.使用适当的密钥大小

请确保为应用程序使用适当的密钥大小。

这个库中有许多防止使用小于256位的HMAC密钥、小于128位的AES密钥或小于1024位的RSA密钥的检查(对于遗留应用程序，2048正在成为新的规范)。但是要注意，其他libs可能不会这样做。

最后，请记住采取所有必要的措施来确保共享或私有密钥的安全性。Nimbus JOSE+JWT已经准备好支持插入硬件安全模块(HSMs)，即在外部设备中执行签名或加密的硬件片段，同时保持操作系统和软件无法访问密钥(以防它们受到攻击)。

原文：https://connect2id.com/products/nimbus-jose-jwt/vulnerabilities

本文：http://pub.intelligentx.net/common-jwt-security-vulnerabilities-and-how-avoid-them

讨论：请加入知识星球或者小红圈【首席架构师圈】