我正在尝试使用JWT为我的RESTful API实现无状态身份验证。
AFAIK，JWT基本上是一个在REST调用期间作为HTTP头传递的加密字符串。
但如果有窃听者看到请求并且窃取令牌怎么办？那么他能用我的身份伪造请求吗？
实际上，此问题适用于所有基于令牌的身份验证。
如何预防？像HTTPS这样的安全渠道？
答案 0 :(得分：223)
我是一个节点库的作者，它在相当深度上处理身份验证express-stormpath，所以我会在这里提供一些信息。
首先，JWT通常是 NOT 加密。虽然有一种方法可以加密JWT（参见：JWEs），但由于种种原因，这在实践中并不常见。
接下来，任何形式的身份验证（使用JWT或不使用JWT）都会受到MitM攻击（中间人）攻击。当您通过互联网发出请求时，攻击者可以查看您的网络流量，就会发生这些攻击。这是您的ISP可以看到的，NSA等。
这有助于防止SSL：通过加密来自计算机的NETWORK流量 - ＆gt;某些服务器在进行身份验证时，监控网络流量的第三方无法看到您的令牌，密码或类似内容，除非他们能以某种方式获取服务器私有SSL密钥的副本（不太可能）。这就是SSL对所有形式的身份验证都是强制性的原因。
然而，假设有人能够利用您的SSL并且能够查看您的令牌：您的问题的答案是是，攻击者将能够使用该令牌冒充您并向您的服务器发出请求。
现在，这是协议的来源。
JWT只是身份验证令牌的一个标准。它们可以用于几乎任何东西。 JWT很酷的原因是你可以在其中嵌入额外的信息，你可以验证没有人搞乱它（签名）。
然而，JWT本身与'安全'无关。对于所有意图和目的，JWT与API密钥或多或少相同：只是随机字符串，用于在某处对某个服务器进行身份验证。
使您的问题更有趣的是使用的协议（最有可能是OAuth2）。
OAuth2的工作方式是，它旨在为客户提供TEMPORARY令牌（如JWT！），以便在短时间内进行身份验证！
这个想法是，如果您的令牌被盗，攻击者只能在短时间内使用它。
使用OAuth2时，您必须经常通过提供用户名/密码或API凭据，然后以交换方式获取令牌来重新对服务器进行身份验证。
因为这个过程经常发生，你的令牌会经常发生变化，让攻击者在不经常遇到大麻烦的情况下不断冒充你“更难”。
希望这有助于^^
答案 1 :(得分：20)
我知道这是一个老问题，但我想我可以在这里降低0.50美元，可能有人可以改进或提供一个论据来完全拒绝我的方法。 我通过HTTPS（ofc）在RESTful API中使用JWT。
为了实现这一目标，您应该始终发布短期令牌（取决于大多数情况，在我的应用中，我实际上将exp声明设置为30分钟，并ttl为3天，因此只要其ttl仍有效且令牌未被列入黑名单，您就可以刷新此令牌。
对于authentication service，为了使令牌无效，我喜欢使用内存缓存层（在我的情况下为 redis ）作为JWT blacklist / {{ 1}}在前面，取决于一些标准：
（我知道它打破了RESTful哲学，但是存储的文件非常短暂，因为我将剩余的生存时间列入黑名单 - ban-list声明 - ）
注意：黑名单代币无法自动刷新
ttl或user.password已更新（需要密码确认），则auth服务会返回刷新的令牌并使之前的令牌无效（黑名单），因此如果您的客户端检测到该用户＆＃39 ; s身份已被某种方式泄露，您可以要求该用户更改其密码。
如果您不想使用黑名单，则可以（但我不鼓励您）验证针对user.email字段的iat（已发布）声明（如果user.updated_at然后JWT无效）。最后，你会像每个人一样正常验证令牌。
注2：而不是使用令牌本身（真的很长）作为缓存的密钥，我建议为jwt.iat < user.updated_at声明生成并使用UUID令牌。哪个好，我想（不确定，因为它刚出现在我的脑海中）你可以使用同样的UUID作为CSRF令牌，通过返回一个jti / secure cookie并正确使用js实现non-http-only标头。这样就可以避免为CSRF检查创建另一个令牌的计算工作。
答案 2 :(得分：4)
很抱歉，在这方面晚了一点，但也有类似的担忧，现在想在同一点上有所作为。
1）rdegges补充了一个很好的观点，即JWT与“安全性”无关，并且仅验证是否有人弄乱了有效载荷（签名）； ssl有助于防止遭到破坏。
2）现在，如果ssl也以某种方式受到威胁，任何窃听者都可以窃取我们的不记名令牌（JWT）并冒充真正的用户，下一步可以做的就是寻求“拥有证明“ 来自客户端的JWT。
3）现在，通过这种方法，JWT的演示者拥有特定的所有权证明（POP）密钥，接收者可以cryptographically确认请求是否来自同一真实用户。
我为此推荐了Proof of Possesion文章，并对此方法深信不疑。
如果能够做出任何贡献，我会很高兴。
干杯（y）
答案 3 :(得分：2)
我们不能仅添加请求生成此JWT令牌的初始主机的ip作为声明的一部分？现在，当JWT被盗并从另一台机器上使用时，当服务器验证此令牌时，我们可以验证所请求的机器ip是否与该机器ip匹配，作为索赔的一部分。这将不匹配，因此令牌可以被拒绝。同样，如果用户尝试通过将自己的ip设置为令牌来操纵令牌，则令牌会随着令牌的更改而被拒绝。
答案 4 :(得分：0)
要解决令牌被盗的问题，请为每个JWT映射有效IP列表。
例如，当用户使用特定IP登录时，可以将该IP添加为该JWT的有效IP，并且当您从另一个IP获得该JWT的请求时（用户更改了Internet或JWT是被盗或出于任何原因），您可以根据自己的使用情况执行以下操作：
建议是否可以改进。
答案 5 :(得分：0)
客户端应该使用用户密码散列的一部分来加密客户端发送http msg到服务器的时间。这部分散列也应该在创建时使用一些服务器密钥加密到令牌中。
服务器可以解密http请求时间并验证短时间延迟。
令牌将更改每个请求。