首先，访问令牌应该是短暂的。可以将其视为短暂的一次性凭据。如果您不相信，请查看此处链接的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，而不将存储的令牌暴露给客户端应用程序。
