我正在使用使用 OAuth 2.0 的 API。它的流程是这样的：
一切对我有用，一切都很好，但我不明白如何处理给定的访问令牌，以便已经授权访问您的应用程序的用户不必再次授予访问权限。等他几天后回来申请时。它会带来糟糕的用户体验（没有人愿意一次又一次地授予访问权限）。
注意：我正在使用Quizlet API
【问题讨论】：
标签： php oauth-2.0 google-oauth access-token
首先，访问令牌应该是短暂的。认为它等于短暂的一次性凭证。如果您不确定，请查看此处链接的 Azure AD 令牌生命周期定义"Configurable token lifetime properties"。
建议使用定义短期访问令牌，例如 1 小时后过期。这样您就可以避免存储它们的复杂性。您只需将它们保存在内存中并使用它们来访问受保护的资源。
我不明白的是如何处理给定的访问令牌，以便已经授权访问您的应用程序的用户不必再次授予访问权限。等他几天后回到应用程序。
嗯，这里你应该说的是Refresh tokens。根据 OAuth 2.0 规范，其刷新令牌具有更长的生命周期。如果您查看我之前对 Azure 的引用，您会发现它们最多可以存活 90 天。对于 Google，刷新令牌会在 6 个月后过期（如果它们未被使用）。仍然可以撤销它们。
现在，当您使用刷新令牌时，您并没有使用它们来访问受保护的资源。应交换刷新令牌以获取访问令牌。因此，如果有人窃取它们，他们仍然需要客户端身份验证（例如：- 客户端 ID、重定向 uri 和客户端密码）来获取访问令牌。不过，保护他们是必须的。
无论如何，RFC6819 定义了一些您可以在5.3.3 部分中采用的可能性来存储秘密（令牌就是秘密）。您可以使用客户端存储机制或利用服务器支持来存储令牌。
如果您的应用程序有后端，一种可能性是将 cookie 与令牌相关联。 Cookie 值可以是您存储在后端（可能在数据库中）的令牌的哈希值。当后端收到具有有效 cookie 值的请求时，它可以检索针对它存储的令牌。这与“记住我”功能非常相似。
如果您无法控制令牌的生命周期（默认情况下它们是长期存在的）怎么办？
如果您可以轻松获得令牌，并且可以损害最终用户体验，请选择内存存储，您将始终检索新令牌以进行新访问。
如果您的应用程序有一个可以维护客户端之间状态的后端，请在后端推送和存储令牌。将客户端会话与令牌相关联，可能通过 cookie/会话。通过后端调用安全 API，无需将存储的令牌暴露给客户端应用程序。
【讨论】：