security - React Native + JWT 还需要刷新 token 吗？

Question

登录时，会从服务器发送一个 JWT 访问 token ，并保存在 RN 的 AsyncStorage 中。

现在我希望用户保持登录状态 5 年，直到他们:

登出

管理员撤销他们的 token

他们在 3 台设备上登录，在其中一台设备上更改密码，这应该将它们从其他 2 台设备上注销，直到他们再次在这些设备上登录

丢失手机，从其他设备登录以退出所有设备

看起来我必须将 JWT token 存储在数据库中(我知道这不是 JWT token 的重点，并且根据我的阅读破坏了它们服务的目的)但我需要知道用户在不同设备上的 token ，以便能够撤销它们。

让我困惑的一件事是阅读访问 token 应该是短暂的，比如 60 分钟，而刷新 token 应该是长期存在的，在我的情况下是 5 年。

我不明白的是为什么我们不能只使用访问 token 来获得 5 年的生命周期(对于每个设备)，将它们保存在数据库中针对用户，以便我们可以识别他们的 token 并根据以下情况撤销他们的 token 上述几点？刷新 token 有什么意义，在这种情况下甚至需要它吗？

注意:我还看到我们不能撤销访问 token ，而只能撤销刷新 token ，所以我真的很困惑。我是否必须同时向 RN 发送访问 token 和刷新 token ，并且仅将刷新 token 用于 Authorization Bearer header 并仅将刷新 token 保存在数据库中？那么如果访问 token 不是数据库中的那个，那么它的意义何在？

我认为这应该很容易实现，但我的标准是 5 年登录并能够根据上述几点撤销 token 。

这种情况的正确解决方案是什么？

Answer 1

访问 token 是短暂的，默认为 24​​ 小时。但为什么？为什么不是5年？

任何拥有访问 token 的人都可以保证访问用户(最初颁发给谁)可以访问的任何内容。这意味着 服务器无法区分该用户和拥有访问 token 的任何其他人 .

没有注销 .我在这里的意思是，您可以将前端重定向到登录页面，让他输入凭据，但服务器中不会​​发生真正的注销。从技术上讲，用户可以使用相同的访问 token 继续获得访问权限(直到过期)

访问 token 不能被撤销 .访问 token 仅在到期时失效。任何人都可以使用它，直到 token 过期。例如，如果到期时间设置为 5 年，而我碰巧获得了您的 token ，我可以拥有您拥有的所有访问权限，直到它到期，在这种情况下为 5 年。这正是将到期时间设置为小于 24 小时更有意义的原因。

现在让我们解决您的疑问。 “我想让用户登录，直到他”

注销

在用户登录后向用户发送刷新 token 。非常安全地存储访问 token 和刷新 token 。在他的访问 token 过期后，使用刷新 token 获取新的访问 token 。循环此操作，直到他注销。当他注销时，在前端删除访问 token 和刷新 token ，并在服务器端撤销刷新 token 。 (同样，如果他以某种方式获得了访问 token ，他仍然可以访问他的帐户，直到它过期)

管理员撤销 token

服务器不能像我之前所说的那样撤销访问 token ，一旦发布其有效期至到期，无论如何 -> 但前提是用户拥有访问 token :P 在他打开应用程序后立即删除访问 token ，如果他在过去 1 小时左右没有打开应用程序。现在，前端被迫使用其存储的刷新 token 获取新的访问 token 。现在，您希望用户强制注销吗？撤销他的刷新 token 。

更改密码后注销所有设备

同2，修改密码后，撤销所有发出的刷新 token (如果不希望用户再次登录，撤销除当前设备外的所有刷新 token )。您在所有设备上的应用都将被迫使用刷新 token 获取新的访问 token ，但由于您撤销了它，用户只能使用其凭据登录。

用户触发的所有设备注销

同 3. 更改密码会在所有设备上触发注销，在这里您只需要添加一个“在所有设备上注销”按钮，该按钮将发送一个服务器请求，该请求撤销除当前设备之外的所有刷新 token 。

警告 : 当前用户 session 无法关闭；您需要等待用户退出应用程序，以便删除当前的访问 token 。解决方法是在他关闭应用程序(甚至最小化应用程序)时立即删除访问 token 或将访问 token 有效期设置为 30 分钟，前提是您可以容忍每次他使用刷新 token 获取新访问 token 所导致的延迟这样做。您需要权衡安全性时间，反之亦然，具体取决于您的应用程序规范。

“没关系，但我首先不想要刷新 token ” (替代解决方案):

我不鼓励存储 token ，因为它会增加因查询数据库而增加的响应时间，从而违背了扩展和防止简单 DDoS 的目的。但是由于 Redis 是在内存上运行的非常快的键值存储，因此有些人更喜欢在其中存储访问 token 。那么它是如何工作的？

设置:用户登录后，发出访问 token 。将其存储在Redis中，然后将其发送给用户。

检查 JWT 签名 && token 的完整性，如果失败 欢呼，没有数据库查询。发回 404 用户未找到。这将与没有 Redis 的 JWT 一样快。

如果成功，请检查 Redis 以获取 token 。如果存在，则授予访问权限。如果没有，请要求用户再次登录。请注意，这比仅使用 JWT 授予访问权限要慢一些，但是，嘿，您没有在其中存储 Postgres 或 Mongo，这可能需要几毫秒才能响应； Redis 是一个键值存储——因为它位于内存(而不是存储)上——比那些快得多。

当且仅当满足两个条件时才授予访问权限:JWT 有效。 JWT 存在于 Redis

回答您的疑问:

现在可以注销。当用户点击注销时，从 Redis 中删除访问 token 。即使他有访问 token ，他也无法登录。访问 token 现在实际上是无效的。

管理员强制注销:从 Redis 中删除该用户的访问 token 。

在服务器成功授予用户访问权限后，您应允许用户发出 请求 删除所有其他具有相同用户 ID(或 uid)的 token ，这将允许注销

更改密码后，发出这样的请求。

在从其他设备注销时，发出这样的请求。

最后遗漏了 1. 保持登录状态直到用户注销:现在您有权使不使用 Redis 时没有的访问 token 失效，只要您实现其他所需的访问 token ，您就可以获得 5 年有效的访问 token 防止滥用访问 token 的安全措施。