关于 JSON Web Token 安全性的一些问题？

Question

我一直在开发一个 Android/IOS 应用程序，它使用 Tomcat API 来发送/接收数据、登录、注销等。我的主要身份验证形式是通过使用 SHA-512 的 HMAC 的 JSON Web 令牌。身份验证照常进行。用户首次登录时提供凭据（用户 ID 和密码）。服务器验证凭据，如果正确，则会生成 JWT 并将其返回给用户，用户可以使用该 JWT 在将来的请求中对自己进行身份验证。该令牌包含指定 userID 的自定义声明，用于了解哪个用户正在发出请求。我做了一些关于 JWT 的研究，对许多问题的看法褒贬不一。我有几个问题希望您能解答一下：

1- 使用 JWT 作为我的 API 的唯一身份验证机制是否足够？

2-在安全性方面，使用HMAC的JWT和使用RSA的JWT有区别吗？

3- 理想情况下，我应该在哪里存储用于签署令牌的对称签名密钥？目前，我将密钥直接传递给生成令牌的函数。这样做安全吗？

4- 我应该定期更改签名密钥以获得更好的安全性吗？

5- 我可以信任插入到令牌中的 userID 声明来识别发出请求的用户吗？

6- 令牌是否有“理想”到期时间？有些人建议最少 15 分钟，而另一些人则说 3 小时就可以了。

7- 我是否应该担心限制特定用户可以拥有的代币数量？用户可能拥有多个移动设备并且在任何时候都可能拥有多个令牌。在这种情况下，只要用户拥有凭据，就没有什么可以阻止他们从我的服务器获取数千个令牌。我应该实现某种机制（例如：数据库）来跟踪用户拥有的令牌吗？如果我在验证/生成令牌时必须进行额外的数据库查询，这似乎违背了 JWT 的目的并增加了复杂性。

8- 我需要担心撤销令牌吗？一些人认为拥有较短到期时间的令牌就足够了。其他人指出，如果用户注销应用程序后不撤销令牌，则永远不可能拥有真正的注销机制。仅仅等待令牌过期是错误的吗？就安全性而言，我什么时候需要撤销令牌？

抱歉发了这么长的帖子。我一直在担心处理这些问题的最佳方法。我很感激任何帮助。谢谢

Answer 1

1- 使用 JWT 作为我的 API 的唯一身份验证机制是否足够？

一般来说是的，只要“签名密钥”具有足够的强度（如果是 HMAC，则为 128 位，由 CSPRNG 生成）。我将在下面的其他答案中讨论它是否“足够”。

2-在安全性方面，使用HMAC的JWT和使用RSA的JWT有区别吗？

如果未选择足够的熵之一，则 HMAC 签名密钥可能会被暴力破解。RSA 不应该有这个缺陷，因为密钥很长，并且在其生成过程中本质上应该已经有足够的熵。

3- 理想情况下，我应该在哪里存储用于签署令牌的对称签名密钥？目前，我将密钥直接传递给生成令牌的函数。这样做安全吗？

您应该将其存储在无法通过网络读取的应用程序配置文件中。这使得它在每个部署中都不同（例如，预发布环境中提供的令牌不能用于生产环境中的身份验证）。

4- 我应该定期更改签名密钥以获得更好的安全性吗？

不，如果它具有足够的强度（128 位熵，如上所述），并且如果它没有被泄露，则不会。

5- 我可以信任插入到令牌中的 userID 声明来识别发出请求的用户吗？

是的，这就是重点。如果您的 HMAC 是根据此声明计算的，则无法更改。

6- 令牌是否有“理想”到期时间？有些人建议最少 15 分钟，而另一些人则说 3 小时就可以了。

这取决于应用程序的“风险偏好”。例如，如果您的应用程序符合 PCI 合规性，则这将是 15 分钟。如果您希望用户将会话保持更长时间，则可以增加此时间。

7- 我是否应该担心限制特定用户可以拥有的代币数量？用户可能拥有多个移动设备并且在任何时候都可能拥有多个令牌。在这种情况下，只要用户拥有凭据，就没有什么可以阻止他们从我的服务器获取数千个令牌。我应该实现某种机制（例如：数据库）来跟踪用户拥有的令牌吗？如果我在验证/生成令牌时必须进行额外的数据库查询，这似乎违背了 JWT 的目的并增加了复杂性。

不，正如你所说，这首先就违背了 JWT 的目标。如果您允许通过 JWT 在客户端管理用户会话，那么您不应该在服务器端跟踪会话。由于令牌是客户端的，因此您的应用程序不应该关心生成了多少令牌，因为您不会产生额外的开销。如果您担心多个用户以同一帐户登录，那么 JWT 不是最佳选择 - 服务器端管理系统会更好，其中发出的令牌只能限制为多个同时会话。

8- 我需要担心撤销令牌吗？一些人认为拥有较短到期时间的令牌就足够了。其他人指出，如果用户注销应用程序后不撤销令牌，则永远不可能拥有真正的注销机制。仅仅等待令牌过期是错误的吗？就安全性而言，我什么时候需要撤销令牌？

这再次归结为“风险偏好”。如果密码被泄露，则很难撤销攻击者可能创建的现有会话。与注销链接类似，您所能做的就是响应客户端请求删除 cookie。

一种方法是在 JWT 中包含上次密码更改的日期和时间，该日期和时间包含在 HMAC 计算中。然后，将对每个请求进行检查，以查明它是否与数据库中的值匹配。如果没有，那么您将拒绝身份验证令牌并强制用户重新登录。这是使用 JWT 进行撤销的一种方法。

注销比较棘手，因为如果您在令牌中包含在服务器端检查的“注销日期/时间”，则一个注销请求将注销所有会话。同样，您的风险偏好将决定这是否值得实施，或者是否更容易设置一个较短的到期期限，以防止攻击者检索到的任何令牌可能继续无限期更新（或者直到用户更改密码，如果您遵循我之前的解决方案）。

过期/密码更改的一般信息

另一种方法是使用过期时间较短的 JWT，但使用后台请求定期刷新它们，或者在处理其他请求时定期刷新它们。通过这种方式，您可以让用户在更方便的时间段内保持登录状态，但在帐户被撤销或密码更改的情况下，您可以将他们重定向到登录屏幕，而不是刷新具有更长有效期的 JWT。