JWT访问令牌和刷新令牌流
这是我的身份验证流程：
- 用户登录后收到两个令牌（具有过期时间的访问令牌和没有过期时间的刷新令牌）
- 对于每个用户，刷新令牌存储在数据库中名为refreshTokens的json列中（这是一个数组）
- 在客户端，访问令牌和刷新令牌都存储在本地存储器上
- 当需要验证用户时，如果访问令牌过期，将使用刷新令牌创建一个新的访问令牌，并将其发送回用户并保持用户登录
- 当用户注销时，数据库中存储的刷新令牌（在refreshTokens列表中）将被删除
我的问题是：
- 这个流程安全吗？
- 我需要在cookie上保存刷新令牌还是本地存储足够好？
共有3个答案
读这篇文章时，我想到了几件事:
> < li>
刷新令牌也需要到期时间。事实上，我认为刷新令牌是一把双刃剑。想象一个场景，其中一个人获得对刷新令牌的访问，他不仅获得对资源的访问，实际上他将获得更多的资源时间。当刷新令牌用于重新生成访问令牌时，我更喜欢重新生成刷新令牌和访问令牌。并且，还要设置一个截止时间。
将刷新令牌存储在数据库中很酷。然而。不过，我确实有另一种选择，您可以轻松使用RSA算法，然后使用私钥生成令牌并使用公钥进行验证。这是为了缓解需要存储刷新令牌的情况。
在客户端，本地存储对我来说是一个很大的否定。我更喜欢的是您使用Http比如说Cookie并将标志设置为true。Http比如说Cookie不会在JS中呈现，而是根据Http协议安全地发送到服务器。这是修复了损害令牌的机会。
你对它的Rest概念已经足够好了。
此流程的一个重要部分是，在第4点中，您使用保存在数据库中的刷新令牌列表来验证RT是否未被撤销。除此之外，它看起来没问题。您可以通过添加过期时间来刷新令牌来增加安全性。然后，即使用户没有主动注销（您没有从数据库中清除RT），RT在一段时间后也将无法使用。
在我看来，将令牌保存在本地存储中已经足够好了。
这个流程是根据OAuth的工作方式以及如何以安全的方式存储令牌来决定的，所以这两个问题都是肯定的。缺少的部分是如何首先获得令牌:为此，使用PCKE的授权代码授权类型是优于遗留隐式授权类型的首选方式。
-
我已经阅读了JWT和访问令牌和刷新令牌。我知道您必须在很短的时间（分钟）内设置访问令牌过期，并在过期时使用刷新令牌获取新的访问令牌。 我不清楚三件事： 谁检查访问令牌是否过期？客户端是否通过发送过期的访问令牌和刷新来检查并请求新的访问代码？ 谁检查刷新令牌是否过期？（显然刷新令牌也需要过期，尽管需要更长的时间才能过期）。 在我看来，如果刷新令牌过期，则必须提示用户重新登录。在某些情况下（移动应用）
-
我正在构建一个使用JWT进行身份验证的应用程序。我开始做一些研究，但对于诸如刷新令牌和令牌存储之类的主题缺乏共识，我感到惊讶。 据我所知，JWT和OAuth是两个不同的协议，它们遵循不同的规范。 但我的问题是，对于一个没有通过第三方资源服务器如Google、Facebook等认证的应用程序，有一个刷新令牌真的有用吗？为什么不让JWT令牌像刷新令牌一样持续时间长。 另一方面，我可以看到，如本文所述，
-
null 很抱歉太啰嗦了。 提前谢了。
-
我不熟悉，它代表。我混淆了它的两个术语：访问令牌和刷新令牌。 用户注册/登录站点后，我创建和。 将刷新标记保存在数据库或cookie中。 15分钟后，用户标记访问令牌过期。 如果用户空闲2小时，我将从cookie或DB中删除刷新令牌，否则我将使用刷新令牌续订访问令牌。 有什么优化的方法可以达到这个目的吗？
-
我正在构建一个移动应用程序，并且正在使用JWT进行身份验证。 最好的方法似乎是将JWT访问令牌与刷新令牌配对，这样我就可以根据需要频繁地使访问令牌过期。 刷新令牌是什么样子的？是随机字符串吗？那串加密了吗？是另一个JWT吗？ 刷新令牌将存储在用户模型的数据库中以便访问，对吗？在这种情况下似乎应该加密 在用户登录后，我是否会将刷新令牌发送回，然后让客户端访问单独的路由来检索访问令牌？
-
我正在做一个项目（没有生产级别，只是为了提高我的技能），我正在使用JWT来处理身份验证。从我所读到的内容来看，仅使用JWT作为访问令牌是非常不安全的，因此我们需要刷新令牌。因此，在登录时，服务器返回一个访问令牌和一个刷新令牌（我将存储在httpOnly cookie中）。访问令牌在短时间内到期，但刷新令牌在到期时用于获取新令牌。 我的问题是，我们何时使用刷新令牌来获取新的访问令牌？是当用户想要获得