使用JWT进行应用程序身份验证和授权

Question

我正在浏览Oauth2文档，并认为这是一种宽容的安全性，因此我尝试使用特殊方案实现JWT令牌，如图片中的移动应用程序与Web API进行通信。

注意：我不喜欢Oauth2刷新令牌的想法，因为它们可能会被盗并允许并行使用（由合法和恶意用户），除非您通过旋转它们来实施盗窃检测（在每次请求时刷新刷新令牌）在这种情况下为什么要使用它们什么？

身份验证流程的工作原理：

1. 使用凭据登录的用户的生命周期为20分钟。
2. 到期后，jwt会通过点击db检查是否被列入黑名单（重新登录），如果没有，则检查是否用于生成新令牌。
3. 如果它从未用于刷新，则接受并用于发出低级访问令牌。
4. 如果之前使用过该令牌，或者其客户端+设备+用户与其父级用户不同，则会提供凭据检查（密码或锁屏代码）
5. 如果通过，此检查会发出一个新的一年级令牌，该令牌将其所有父级和子级列入黑名单，就像新的第一个用户登录一样。
6. 如果锁屏失败，则会向用户显示登录屏幕。

问题是：

1. 可能存在哪些安全漏洞？ （我发现了两个用例：被盗的有效访问令牌与Oauth令牌持续20分钟相同的问题。此处没有任何损失。窃取睡眠令牌：用户未登录7天，令牌被盗并被使用，直到用户再次登录或者令牌链在3个月的持久性后重新发布 - 我们的政策 - 这种盗窃的机会很小，因为令牌必须在用户对应用程序做出的最后一次请求时被截获，比窃取Oauth2刷新令牌更轻薄）
2. 在此计划中，玩家可能会对应用程序造成什么样的用户体验问题？

Answer 1

OAuth2 refresh tokens并不适合移动客户端使用。使用刷新令牌需要客户端凭据，这些凭据无法安全地存储在移动应用程序中。

刷新令牌用于confidentials客户端（例如服务器端Web应用程序）。它们通常在使用时更新（服务器发回新访问和新刷新令牌）。与访问令牌相反，刷新令牌仅发送到授权服务器，而不是资源（API）服务器。

关于您的身份验证流程。第2步是IMO的薄弱环节。您允许客户端使用过期的令牌生成新的访问令牌。因此，如果我找到您的手机并访问该设备，它将允许我获取新的访问令牌并冒充您。

您可以强制客户端每隔15分钟刷新一次令牌，但是您必须定义在应用关闭或设备关闭时会发生什么？是否可以再次重新验证用户？