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

Question

我了解使用访问/刷新令牌的身份验证过程如下：

1. 为 refresh_token 交换用户名/密码
2. 使用 refresh_token 获取 access_token
3. 将 access_token 用于请求（无需 DB 调用）
4. 如果 access_token 已过期 -> 使用 refresh_token 获取新的（需要 DB 调用）

管理/撤销访问的流程：

1. 为 refresh_token 交换用户名/密码
2. 将 refresh_token 存储在数据库中
3. 使用 refresh_token 获取 access_token 时检查 DB 中的已撤销标志
4. 通过设置撤销标志来阻止

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

用户体验：

时需要登录

• 第一次访问
• refresh_token 已撤销
• refresh_token 已过期

安全隐患：

• refresh_token 被盗：在手动撤销之前或很长一段时间内易受攻击
• access_token 被盗：短时间内易受攻击。无法撤销
• 注销：access_token 一直有效，直到过期/无法撤销

没有 refresh_token： +没有长期存在的漏洞 -糟糕的用户体验。用户需要经常登录

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

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

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

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

Answer 1

创建新的 access_token 并为旧令牌设置撤销。 （可选地， 到期后仅允许此操作 x 次。这相当于 refresh_token 的到期日期）

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

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