我不能很好地理解JWT身份验证

Question

如今，许多开发人员使用JWT身份验证来授权api调用。 顺便说一句，如果黑客可以捕获经过身份验证的用户的api呼叫请求，那么他可以拥有经过身份验证的JWT令牌。 然后，黑客可以使用授权的JWT令牌访问此API，而无需进行身份验证。 这好吗？ 我想知道JWT身份验证实际上是安全的。 你能解释一下吗？

Answer 1

jwt是包含有关用户身份和声明的信息的代码，仅在有限的时间内有效。

除了颁发令牌的授权终端之外，任何人都无法读取或更改代码。因此，安全无法被篡改。这意味着令牌可以完全信任。您无需验证令牌，您可以使用身份信息和声明，而无需咨询数据库。

但这也是缺点。一旦发出，令牌有效，直到它过期，因为过期不能改变。这就是令牌只应通过安全线路发送到服务器的原因。您不希望黑客拦截令牌。

但如果它发生了，那么呢？

有几种选择。您可以使用短期令牌，这意味着令牌在发布后很短的时间到期。如果一个令牌被截获，它只在很短的时间内有效。在这种情况下，您理所当然地认为黑客可以在有限的时间内访问系统。优点是你需要更少的资源，而且黑客的努力可能是不值得的。

另一种选择是在每个请求上验证令牌。这需要更多资源（例如，在数据库中查找），但您可以使用某种缓存。如果某些内容发生了变化，例如IP地址，那么您可以使令牌无效。但问题是你是否可以检测到黑客是否发送了令牌。

所以这取决于所选择的策略。 但是：如果您发出长期访问令牌而无需验证（因此无法撤销令牌），那么您将会如果黑客获得访问令牌，则会出现问题。因此，您需要做一些事情以安全的方式使用它。

虽然我认为这应该足以帮助您理解，但我想提及使用刷新令牌。如果您使用短期访问令牌，那么您可能希望实现长期刷新令牌。这些刷新令牌用于在到期后获取新的访问令牌。优点是您不需要发送凭证，refesh令牌就足够了。但是，您只能在可以保密的应用程序中实现此功能。因为你肯定不希望黑客拦截（长期存在的）刷新令牌。

使用频率较低（与访问令牌相对），您可以添加逻辑以在使用时验证刷新令牌。您可以查阅数据库并决定拒绝请求（例如，当IP地址更改时）并撤消刷新令牌。在这种情况下，用户必须再次识别自己（发送凭证）。

Answer 2

JWT只是fsb服务器和客户端之间的安全msg传输器，因此fsb服务器可以确定客户端是否已登录;如果登录，fsb服务器将获取基于个人唯一用户的数据。

1. google oauth

   1. G仅在用户拥有Google帐户并成功正确输入gmail和密码时才将用户gid发回我的服务器。
   2. 用户ID保存在jwt的有效负载中。

2. JWT

   1. 如果谷歌验证用户并且谷歌返回gid
   2. 创建jwt内容和内部维护：exp date，encryption
   3. jwt被发送并存储在用户浏览器的本地存储中;
   4. 每个用户的req将jwt发送回我的服务器
   5. 我的服务器使用secretOrKey解码jwt，这只是我的服务器所拥有的，并从jwt获取内容（uid）。
   6. 如果uid在我的数据库中，则用户已经注册并且现在已经登录。
   7. 将我的数据库中请求的数据发送给用户，因为他已登录
   8. 如果使用因密码错误或G电子邮件而无法进行Google验证，则无法创建jwt。

3. JWT的过程

   1. 用户的Google弹出登录
   2. google服务器将信息返回给我的服务器。如果gid不在我的数据库中，我会将其保存在我的数据库中，以便用户可以注册。
   3. 创建jwt并添加uid作为内容。到期日。
   4. jwt被发送并存储在用户浏览器的本地存储中
   5. 用户通过http请求页面，它包含jwt。我的服务器通过登录确定测试检查该用户是否登录：如果用户的jwt uid在我的数据库中，则用户登录。用户请求的数据将被提供给用户。如果用户没有jwt或uid不匹配，则用户无法登录，请将用户发送到登录页面。

JWT说明

1. https://medium.com/@rahulgolwalkar/pros-and-cons-in-using-jwt-json-web-tokens-196ac6d41fb4
2. https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
3. https://scotch.io/tutorials/the-anatomy-of-a-json-web-token
4. https://auth0.com/blog/cookies-vs-tokens-definitive-guide/