我是否正确理解用于身份验证的访问和刷新令牌技术？
- 登录后，返回用户访问令牌并刷新令牌（对两者使用相同的技术JWT）。
- 正在数据库中保存刷新令牌（一个用户可以拥有多个设备的多个刷新令牌）。
- 每当用户发送带有无效访问令牌的请求时，请检查Refresh Token并调用另一个api以获得新的访问令牌（在客户端执行此操作）。之后，调用api以使用新的访问令牌再次获取数据。
- 如果刷新令牌无效，则删除其在数据库中的记录，用户必须重新登录才能获得新的刷新令牌。
我是否正确理解访问和刷新令牌技术？请给我一些建议。提前感谢。
共有1个答案
在你列出的4个步骤中，有些看起来或多或少正确，而有些则不正确。我将首先给出为什么创建刷新令牌的前提，以及它们的主要目的是什么。
使用只带有访问令牌的JWT模式，当JWT令牌过期时，存在潜在的可用性问题。以银行网站为例。当用户登录时，他会收到一个具有特定过期期的JWT令牌（通常存储在令牌的claims部分的exp键下）。如果给出令牌5分钟过期，那么从可用性的角度来看，这意味着网站必须强制用户每5分钟手动登录一次。显然，这不是最好的用户体验，因为这意味着当令牌过期时，碰巧处于某个业务流程中间的用户可能会失去所有的工作。这就是刷新令牌来缓解此问题的地方。
使用带有刷新令牌的JWT模式意味着用户同时接收访问和刷新令牌。这里的典型工作流可能是：
-
null
-
我试图弄清楚我应该如何坚持身份验证。 假设用户使用电子邮件和密码成功进行身份验证。然后服务器生成并返回两个令牌： accesstoken（jwt过期15分钟）将存储在浏览器存储中 refreshtoken（jwt过期7天）作为安全cookie 当将访问令牌存储在本地存储（或会话存储）中时，React 应用程序将简单地检查它是否存在于存储中并继续渲染私有路由。因此，这意味着如果用户有一个无效/被盗的
-
我正在做一个项目（没有生产级别，只是为了提高我的技能），我正在使用JWT来处理身份验证。从我所读到的内容来看，仅使用JWT作为访问令牌是非常不安全的，因此我们需要刷新令牌。因此，在登录时，服务器返回一个访问令牌和一个刷新令牌（我将存储在httpOnly cookie中）。访问令牌在短时间内到期，但刷新令牌在到期时用于获取新令牌。 我的问题是，我们何时使用刷新令牌来获取新的访问令牌？是当用户想要获得
-
我正在尝试使用 NodeJS 构建 RESTful API，但在 api 调用期间无法理解使用令牌对用户进行身份验证的正确方法。在阅读了一些博客和文章后，我想出了这些方法： Access Token（AT）是包含唯一userId作为JWT有效负载的JWT令牌。1天后到期。 刷新令牌（RT）是使用uuid npm包的随机uuid。与用户文档一起存储在数据库中。 过程： 当用户登录/注册服务器发布新A
-
null 我的自定义rest筛选器： 上面的内容实际上会导致应用程序启动时出现一个错误：有人能告诉我如何最好地执行此操作吗？pre_auth筛选器是执行此操作的最好方法吗？ 编辑 使用Spring-security实现解决方案 希望它能帮助其他人…
-
我询问了如何建立一个服务呼叫，并在HttpClient上获得了一个很好的信息。然而，虽然这个问题在技术上得到了回答，但我还是被卡住了。 在控制台中，我可以看到我的浏览器向服务发送了什么请求来获取授权令牌。然而，当我尝试在我的服务层中模拟构建请求的调用时，我得到以下错误消息。我在这里犯错的可能性很大。不知道该用谷歌搜索什么，真的。。。 "StatusCode： 500， ReasonPhrase：'
-
我正在构建一个基于令牌的身份验证(Node.js使用带有angular客户端的passport/JWT)。 用户输入凭证后，他将获得一个访问令牌，并在头中的每个请求中发送该令牌（头：bearer token）。 我不想每次他的访问令牌过期时都提示登录请求（我猜大约每天），我听说过刷新令牌。刷新令牌永不过期（或很少过期），并且能够无限期续订令牌。当访问令牌即将过期时，客户端可以通过发送刷新令牌来发送