JWT刷新令牌流
我正在构建一个移动应用程序，并且正在使用JWT进行身份验证。
最好的方法似乎是将JWT访问令牌与刷新令牌配对，这样我就可以根据需要频繁地使访问令牌过期。
- 刷新令牌是什么样子的？是随机字符串吗？那串加密了吗？是另一个JWT吗？
- 刷新令牌将存储在用户模型的数据库中以便访问，对吗？在这种情况下似乎应该加密
- 在用户登录后，我是否会将刷新令牌发送回，然后让客户端访问单独的路由来检索访问令牌？
共有2个答案
下面是撤销JWT访问令牌的步骤：
- 登录时，发送2个令牌（访问令牌、刷新令牌）以响应客户端。
- 访问令牌的过期时间较短，刷新的过期时间较长。
- 客户端（前端）将在其本地存储中存储刷新令牌，并在Cookie中存储访问令牌。
- 客户端将使用访问令牌来调用API。但过期时，从本地存储中选择刷新令牌，并调用身份验证服务器API以获取新令牌。
- 您的身份验证服务器将公开一个API，它将接受刷新令牌并检查其有效性，并返回一个新的访问令牌。
- 刷新令牌过期后，用户将被注销。
请让我知道，如果你需要更多的细节，我可以分享代码（Java+spring boot）以及。
对于您的问题：
Q1:这是另一个JWT,在很长的过期时间内提交的声明较少。
Q2:它不会在数据库中。后端不会在任何地方存储。他们只需用私钥/公钥解密令牌，并用其过期时间来验证它。
Q3:是的，正确
假设这是关于OAuth2.0的，因为它是关于JWT和刷新令牌的...：
>
就像访问令牌一样，原则上刷新令牌可以是任何内容，包括您描述的所有选项；当授权服务器希望是无状态的或者希望对提供它的客户机强制某种“占有证明”语义时,可以使用JWT；请注意，刷新令牌与访问令牌的不同之处在于，它不提供给资源服务器，而只提供给最初发出它的授权服务器，因此对于JWTs-as-access-tokens的自包含的验证优化对于刷新令牌不成立
这取决于数据库的安全性/访问；如果数据库可以被其他方/服务器/应用程序/用户访问，那么是的（但您的里程数可能会因您存储加密密钥的位置和方式而异……)
授权服务器可以同时发行访问令牌和刷新令牌，这取决于客户机用来获得它们的授权；规范包含每个标准化赠款的详细信息和选项
-
我正在构建一个使用JWT进行身份验证的应用程序。我开始做一些研究，但对于诸如刷新令牌和令牌存储之类的主题缺乏共识，我感到惊讶。 据我所知，JWT和OAuth是两个不同的协议，它们遵循不同的规范。 但我的问题是，对于一个没有通过第三方资源服务器如Google、Facebook等认证的应用程序，有一个刷新令牌真的有用吗？为什么不让JWT令牌像刷新令牌一样持续时间长。 另一方面，我可以看到，如本文所述，
-
这是我的身份验证流程： 用户登录后收到两个令牌（具有过期时间的访问令牌和没有过期时间的刷新令牌） 对于每个用户，刷新令牌存储在数据库中名为refreshTokens的json列中（这是一个数组） 在客户端，访问令牌和刷新令牌都存储在本地存储器上 当需要验证用户时，如果访问令牌过期，将使用刷新令牌创建一个新的访问令牌，并将其发送回用户并保持用户登录 当用户注销时，数据库中存储的刷新令牌（在refre
-
我正在使用Tymon提供的包来处理从我的laravel后端到spa前端的Auth，我正在创建AuthController，这几乎是我从文档中获取的，只是稍微调整一下它以满足我的需要。从登录到注销以及令牌过期，一切正常。 问题是，我确实看到该控制器上有一个令牌刷新功能，如果我的猜测是正确的，那就是刷新客户端已经拥有的当前令牌。但是怎么做呢？如何处理前端上的刷新令牌？因为它是相当烦人的，每60分钟（默
-
问题内容： 我们的React Native Redux应用程序使用JWT令牌进行身份验证。有许多操作需要此类令牌，并且例如在应用加载时会同时分派许多令牌。 例如 双方并要求JWT。我们将令牌保存在和中。我的问题是如何处理令牌到期。 最初，我将使用中间件来处理令牌到期 } 我遇到的问题是，对于令牌和操作，都会刷新令牌，因为在分发令牌和令牌时，令牌将过期。理想情况下，我想“暂停”需要身份验证的操作
-
在一个小项目上工作并使用jwt令牌进行了一些身份验证，整个过程如下所示： < li >在auth/register上生成jwt令牌以及刷新令牌 < li >使用令牌发出请求 < li >如果令牌过期，我将查询请求用户及其refreshToken，比较其当前请求refreshToken和数据库令牌 < li >如果令牌匹配，我将生成一个新令牌和一个新刷新令牌。 整个问题是第五步，假设我向“/me/f