为什么我们不应该使用access_token作为refresh_token

Question

我理解使用访问/刷新令牌的身份验证过程的工作方式如下：

1. 刷新refresh_token的用户名/密码
2. 使用refresh_token获取access_token
3. 对请求使用access_token（不需要数据库调用）
4. 如果access_token已过期 - ＆gt;使用refresh_token获取一个新的（需要DB调用）

管理/撤销访问权限的流程：

1. 刷新refresh_token的用户名/密码
2. 在数据库中存储refresh_token
3. 使用refresh_token获取access_token
时，检查数据库中的吊销标志
4. 通过设置撤销标志阻止

数据库交互： 只需要刷新令牌。即频率取决于access_token的生命周期。

用户体验：

时需要登录
• 首次访问
• refresh_token已撤销
• refresh_token已过期

安全隐患：

• refresh_token被盗：在手动撤销或长时间使用之前容易受到攻击
• access_token被盗：脆弱的短时间。无法撤销
• 注销：access_token保持有效，直到过期/无法撤销

没有refresh_token： +没有长期存在的漏洞 -Bad UX。用户需要经常登录

现在我想知道为什么我们不能只使用access_token作为refresh_token：

1. 用于访问access_token的用户名/密码
2. 在数据库中存储access_token
3. 对所有请求使用access_token（无数据库调用）
4. 过期时：检查DB是否设置了撤销标志。如果不是 - ＆gt;创建新的access_token并为旧令牌设置revoked。 （可选，仅限 在到期后允许这个x时间。这相当于一个 refresh_token的到期日期）

现在UX / security / DB_call_frequency似乎完全相同。那么为什么我们需要一个单独的refresh_token？

我能看到的唯一一个论点就是将它们分开会降低refresh_token被盗的风险，因为它的发送频率较低。

Answer 1

  

创建新的access_token并为旧令牌设置已撤销。 （任选地，   到期后只允许x时间。这相当于   refresh_token的过期日期

您想通过交换用户名和密码再次执行此操作吗？

如果是，那么用户需要再次登录。您可以使用仅发送访问令牌的客户端凭据授予https://tools.ietf.org/html/rfc6749#section-4.4或隐式流https://tools.ietf.org/html/rfc6749#section-4.2，这些流不会发送刷新令牌。如果您可以发送用户名和密码，则可以使用客户端凭据授予，并在每次过期时请求访问令牌。