我正在尝试使用JWT为我的RESTful API实现无状态身份验证 .
AFAIK，JWT基本上是在REST调用期间作为HTTP头传递的加密字符串 .
但是，如果有一个窃听者看到了请求并窃取了令牌呢？那么他能用我的身份伪造请求吗？
实际上，这种关注适用于所有基于令牌的身份验证 .
怎么预防？像HTTPS这样的安全渠道？
我是一个节点库的作者，它在很大程度上处理了身份验证，所以我会在这里提供一些信息 .
首先，JWT通常不加密 . 虽然有一种方法可以加密JWT（参见：JWEs），但由于许多原因，这在实践中并不常见 .
接下来，任何形式的身份验证（使用JWT或不使用JWT）都会受到MitM攻击（中间人）攻击 . 当您通过互联网发出请求时，攻击者可以查看您的网络流量，就会发生这些攻击 . 这是您的ISP可以看到的，NSA等 .
这有助于防止以下情况：通过加密来自计算机的NETWORK流量 - >某些服务器在进行身份验证时，监控网络流量的第三方无法看到您的令牌，密码或类似内容，除非他们能够以某种方式获取服务器私有SSL密钥的副本（不太可能） . 这就是SSL对所有形式的身份验证都是强制性的原因 .
但是，假设有人能够利用您的SSL并且能够查看您的令牌：您的问题的答案是肯定的，攻击者将能够使用该令牌冒充您并向您的服务器发出请求 .
现在，这是协议的来源 .
JWT只是身份验证令牌的一个标准 . 它们可以用于几乎任何东西 . JWT很酷的原因是你可以在其中嵌入额外的信息，你可以验证没有人搞乱它（签名） .
但是，JWT本身与“安全”无关 . 对于所有意图和目的，JWT与API密钥或多或少相同：只是随机字符串，用于在某处对某个服务器进行身份验证 .
是什么让你的问题更有趣，是使用的协议（很可能是OAuth2） .
OAuth2的工作方式是，它旨在为客户提供TEMPORARY令牌（如JWT！），以便在短时间内进行身份验证！
我们的想法是，如果您的令牌被盗，攻击者只能在短时间内使用它 .
使用OAuth2时，您必须经常通过提供用户名/密码或API凭据，然后以交换方式获取令牌来重新对服务器进行身份验证 .
因为这个过程经常发生，所以你的令牌会经常变化，让攻击者更加难以不经常冒犯你 .
希望这有助于^^
我知道这是一个老问题，但我想我可以在这里降低0.50美元，可能有人可以改进或提供一个论据来完全拒绝我的方法 . 我在HTTPS（ofc）的RESTful API中使用JWT .
为了实现这一点，你应该总是发行短期令牌（取决于大多数情况，在我的应用程序中，我实际上将 exp 声明设置为30分钟，并且 ttl 设置为3天，因此您可以刷新此令牌，只要它的 ttl 仍然有效且令牌未被 blacklisted ）
exp
ttl
对于 authentication service ，为了使令牌无效，我喜欢使用内存缓存层（在我的情况下为redis）作为前面的 JWT blacklist / ban-list ，具体取决于一些标准:(我知道它打破了RESTful哲学，但是存储的文件真的很短暂，因为我将剩余的生存时间列入黑名单 - ttl 索赔 - ）
authentication service
JWT blacklist
ban-list
Note: blacklisted tokens can't be automatically refreshed
如果 user.password 或 user.email 已更新（需要密码确认），则auth服务返回刷新的令牌并使前一个令牌无效（黑名单），因此如果您的客户端检测到用户想要使用黑名单，则可以（但我不鼓励你）对 user.updated_at 字段验证 iat （发布于）声明（如果 jwt.iat < user.updated_at 则JWT无效） .
user.password
user.email
user.updated_at
iat
jwt.iat < user.updated_at
用户故意退出 .
最后，您通常会像每个人一样验证令牌 .
Note 2: 而不是使用令牌本身（它真的很长）作为缓存的密钥，我建议为 jti 声明生成和使用UUID令牌 . 哪个好，我想（不确定，因为它只是出现在我脑海中）你可以使用与CSRF令牌相同的UUID，通过返回 secure / non-http-only cookie并使用js正确实现 X-XSRF-TOKEN 标头 . 这样您就可以避免为CSRF检查创建另一个令牌的计算工作 .
jti
secure
non-http-only
X-XSRF-TOKEN
2 回答
我是一个节点库的作者，它在很大程度上处理了身份验证，所以我会在这里提供一些信息 .
首先，JWT通常不加密 . 虽然有一种方法可以加密JWT（参见：JWEs），但由于许多原因，这在实践中并不常见 .
接下来，任何形式的身份验证（使用JWT或不使用JWT）都会受到MitM攻击（中间人）攻击 . 当您通过互联网发出请求时，攻击者可以查看您的网络流量，就会发生这些攻击 . 这是您的ISP可以看到的，NSA等 .
这有助于防止以下情况：通过加密来自计算机的NETWORK流量 - >某些服务器在进行身份验证时，监控网络流量的第三方无法看到您的令牌，密码或类似内容，除非他们能够以某种方式获取服务器私有SSL密钥的副本（不太可能） . 这就是SSL对所有形式的身份验证都是强制性的原因 .
但是，假设有人能够利用您的SSL并且能够查看您的令牌：您的问题的答案是肯定的，攻击者将能够使用该令牌冒充您并向您的服务器发出请求 .
现在，这是协议的来源 .
JWT只是身份验证令牌的一个标准 . 它们可以用于几乎任何东西 . JWT很酷的原因是你可以在其中嵌入额外的信息，你可以验证没有人搞乱它（签名） .
但是，JWT本身与“安全”无关 . 对于所有意图和目的，JWT与API密钥或多或少相同：只是随机字符串，用于在某处对某个服务器进行身份验证 .
是什么让你的问题更有趣，是使用的协议（很可能是OAuth2） .
OAuth2的工作方式是，它旨在为客户提供TEMPORARY令牌（如JWT！），以便在短时间内进行身份验证！
我们的想法是，如果您的令牌被盗，攻击者只能在短时间内使用它 .
使用OAuth2时，您必须经常通过提供用户名/密码或API凭据，然后以交换方式获取令牌来重新对服务器进行身份验证 .
因为这个过程经常发生，所以你的令牌会经常变化，让攻击者更加难以不经常冒犯你 .
希望这有助于^^
我知道这是一个老问题，但我想我可以在这里降低0.50美元，可能有人可以改进或提供一个论据来完全拒绝我的方法 . 我在HTTPS（ofc）的RESTful API中使用JWT .
为了实现这一点，你应该总是发行短期令牌（取决于大多数情况，在我的应用程序中，我实际上将
exp声明设置为30分钟，并且ttl设置为3天，因此您可以刷新此令牌，只要它的ttl仍然有效且令牌未被 blacklisted ）对于
authentication service，为了使令牌无效，我喜欢使用内存缓存层（在我的情况下为redis）作为前面的JWT blacklist/ban-list，具体取决于一些标准:(我知道它打破了RESTful哲学，但是存储的文件真的很短暂，因为我将剩余的生存时间列入黑名单 -ttl索赔 - ）Note: blacklisted tokens can't be automatically refreshed
如果
user.password或user.email已更新（需要密码确认），则auth服务返回刷新的令牌并使前一个令牌无效（黑名单），因此如果您的客户端检测到用户想要使用黑名单，则可以（但我不鼓励你）对user.updated_at字段验证iat（发布于）声明（如果jwt.iat < user.updated_at则JWT无效） .用户故意退出 .
最后，您通常会像每个人一样验证令牌 .
Note 2: 而不是使用令牌本身（它真的很长）作为缓存的密钥，我建议为
jti声明生成和使用UUID令牌 . 哪个好，我想（不确定，因为它只是出现在我脑海中）你可以使用与CSRF令牌相同的UUID，通过返回secure/non-http-onlycookie并使用js正确实现X-XSRF-TOKEN标头 . 这样您就可以避免为CSRF检查创建另一个令牌的计算工作 .