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

Question

现在很多开发者使用 JWT Authentication 来授权 api 调用。顺便说一句，如果黑客可以捕获经过身份验证的用户的 api 调用请求，那么他就可以获得经过身份验证的 JWT 令牌。然后黑客可以使用授权的 JWT 令牌访问这个 api，而无需他的身份验证。这可以吗？我想知道 JWT 身份验证实际上是安全的。你能解释一下吗？

score 1 · Accepted Answer

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

除了颁发令牌的授权端点之外，任何人都无法读取或更改该代码。因此，在不可篡改的意义上，它是安全的。这意味着令牌可以被完全信任。您不必验证令牌，并且可以使用身份信息和声明，而无需查阅数据库。

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

但如果发生了，那又如何呢？

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

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

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

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

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

score 0 · Accepted Answer

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

谷歌认证
1. 仅当用户拥有 google 帐户并正确输入 gmail 和密码时，G 才会将用户 gid 发送回我的服务器。
2. 用户 ID 保存在 jwt 的有效负载中。
jwt
1. 如果谷歌验证用户并且谷歌返回 gid
2. 创建jwt内容和内部维护：exp date，加密
3. jwt 被发送并存储在用户浏览器的本地存储中；
4. 每个用户的请求将 jwt 发送回我的服务器
5. 我的服务器使用只有我的服务器拥有的 secretOrKey 解码 jwt，并从 jwt 获取内容（uid）。
6. 如果 uid 在我的数据库中，则用户已经注册并且现在已经登录。
7. 将请求的数据从我的数据库发送给用户，因为他已登录
8. 如果由于密码错误或 G 电子邮件而导致使用失败 google 验证，则不会创建 jwt。
智威汤逊的流程
1. 用户的谷歌弹出登录
2. 谷歌服务器将信息返回到我的服务器。如果 gid 不在我的数据库中，我会将其保存在我的数据库中，以便可以注册用户。
3. 创建 jwt 并将 uid 添加为内容。过期日期。
4. jwt被发送并存储在用户浏览器的本地存储中
5. 用户通过 http 请求一个页面，它包含 jwt。我的服务器通过登录确定测试检查此用户是否登录：如果用户的 jwt uid 在我的数据库中，则用户已登录。用户请求的数据将提供给用户。如果用户没有 jwt 或 uid 不匹配，则用户未登录，将用户发送到登录页面。

智威汤逊描述

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

2 回答 2

Related

Reference