使用JWT和刷新令牌对移动应用程序进行身份验证
现在我想知道如何集成刷新令牌。如何确保用户只能使用已颁发给该设备的有效刷新令牌获得新的访问令牌？或者，我是否使事情过于复杂，并分配一个刷新令牌，可以在alle设备上使用，这将是一个诀窍？
更新：我已经研究了doorkeeper gem，它支持密码授予流。但是doorkeeper处理令牌的方式是，它将每个生成的访问令牌与相应的刷新令牌存储在数据库中。当令牌被撤消或刷新时，旧的访问令牌将失效--随着时间的推移，这将变成一个巨大的数据库表。
另外，我更喜欢使用JWT作为令牌，这样除了在数据库中存储刷新令牌之外，我不必存储任何东西。下面的过程是否安全？
- 用户使用用户名/密码和设备名请求访问令牌。
- 服务器发出JWT并为当前设备创建刷新令牌。
- 服务器存储刷新令牌。
- 当访问令牌过期时，用户使用它的刷新令牌请求一个新令牌。
- 服务器验证刷新令牌并发出新的访问令牌。此外，刷新令牌将被替换为新令牌。
我的问题是：用户可以在多个设备上登录，如何区分它们？
共有1个答案
我所看到的工作方式是，服务器返回一个未授权状态(401)，其中包含一条消息，指示访问令牌已过期，但客户机只有一次机会使用该过期令牌请求一个新令牌。一旦客户端使用过期令牌请求新令牌，过期令牌就会失效，不能再使用。这样你就可以继续用旧代币换新代币了。
如果您的过期时间很短，被盗令牌仍然有效的可能性非常小，但从UX的角度来看，用户将保持登录状态，因为令牌协商可以在后台进行。只有当用户注销或他们正在使用的令牌在服务器端显式无效时，用户的令牌才会无效。
对于您拥有的每个用户名/密码组合，您绝对应该有一个唯一的令牌。应用程序中的每个客户端都有相同的令牌是非常不安全的。
-
我正在做一个项目（没有生产级别，只是为了提高我的技能），我正在使用JWT来处理身份验证。从我所读到的内容来看，仅使用JWT作为访问令牌是非常不安全的，因此我们需要刷新令牌。因此，在登录时，服务器返回一个访问令牌和一个刷新令牌（我将存储在httpOnly cookie中）。访问令牌在短时间内到期，但刷新令牌在到期时用于获取新令牌。 我的问题是，我们何时使用刷新令牌来获取新的访问令牌？是当用户想要获得
-
我正在尝试为我的应用程序构建一个身份验证解决方案。我使用React作为前端，使用API模式下的Rails作为后端。我有一个外部身份验证解决方案，我需要使用它。我无意中发现了Knock for JWT令牌管理，但我不理解文档，尤其是这部分“它必须有一个身份验证方法，类似于has_secure_password添加的方法”，因为由于我的外部身份验证服务，我没有用户模型。因此，在我的头脑中，登录请求将发
-
我试图弄清楚我应该如何坚持身份验证。 假设用户使用电子邮件和密码成功进行身份验证。然后服务器生成并返回两个令牌： accesstoken（jwt过期15分钟）将存储在浏览器存储中 refreshtoken（jwt过期7天）作为安全cookie 当将访问令牌存储在本地存储（或会话存储）中时，React 应用程序将简单地检查它是否存在于存储中并继续渲染私有路由。因此，这意味着如果用户有一个无效/被盗的
-
我引用的是另一篇讨论在JWT中使用刷新令牌的SO帖子。 JWT（JSON Web令牌）自动延长到期时间 我有一个应用程序，它具有一个非常通用的体系结构，在这个体系结构中，我的客户机（web和移动）与一个REST API对话，然后再与一个服务层和数据层对话。 令牌每小时由客户端刷新一次。 如果用户令牌未被刷新（用户处于非活动状态且应用程序未打开）并且过期，则无论何时他们想要恢复，都需要登录。 我看到
-
我正在尝试访问一个我在Azure上托管并用Azure AD保护的API应用程序。 对于API应用程序，我已经设置了App Service Authentication=Azure Active Directory“Express”管理模式。 在“Classic”门户中，我在AD下创建了几个应用程序。一个用于API应用程序，另一个用于Web应用程序。对于Web应用程序，我在API应用程序的“对其他应
-
jwt不应该仅仅用于认证用户吗？我读到过可以在里面存储非敏感的东西，比如用户ID。将权限级别之类的东西存储在令牌中可以吗？这样我可以避免数据库调用。