【发布时间】：2021-07-06 14:56:57
【问题描述】：
我有一个 IdentityServer4 的实现，它与 Azure AD 连接以进行身份验证 (OIDC)。在回调方法中，我使用 IdentityServertools 生成 access_token 并将用户重定向到 SPA。然后 SPA 将 access_token 存储到 localstorage 中并用于身份验证。
通常，当我的 SPA 应用程序访问 IdentityServer4 的令牌端点时，它会提供 access_token 和 refresh_token，然后使用 refresh_token 重新验证返回的用户。
在这种 SSO 与 Azure AD 的情况下，我是否需要手动生成 refresh_token？如果是，我可以在默认实现之上构建，这不是问题 (However, the docs suggest against of changing the IRefreshTokenService implementation or building something from scratch)
我真正的问题是，这里需要 refresh_token 吗？因为 refresh_tokens 存储在 DB 中并且永远不会被删除，并且一段时间后，这些 refresh_tokens 表会膨胀（现在它已经有 80k 行）。用户应该点击 SAP Successfactor 中的一个小图块——这将打开 Azure 的登录/同意屏幕，或者直接将用户带到主页面，在该页面中，哲将回答一个问题并完成。因此，这几乎不是 2-3 分钟的业务。因此，我可以继续为每次点击从我的 IdentityServer4 生成 access_tokens，因为如果 zhe 从 SAP 的 Successfactor（或与 Azure 链接的任何其他应用程序）注销，我不希望用户在浏览器中保持身份验证。
请指教，我是否应该生成refresh_token？它是一个好的架构吗？
【问题讨论】：
-
我不清楚你的结构，但我想我可以分享一些我的经验。访问令牌用于证明允许请求访问资源（例如来自 ms 的 api 或您的自定义 api），刷新令牌用于刷新访问令牌以确保访问令牌未过期。默认情况下，访问令牌将在一小时内到期，刷新令牌有 90 天。所以我通常将刷新令牌存储在 azure key vault 中，所以当我想刷新访问令牌时，我会获取刷新令牌。并且每次返回一个新的访问令牌时，都会返回一个新的刷新令牌，所以替换它。
-
刷新令牌的过期时间远长于访问令牌的过期时间。所以我们很容易发现它是为一些特殊场景设计的，因为我们还可以通过其他方式生成新的访问令牌，例如使用 msal 或重新登录。正如您在问题中所说，您可以一键生成访问令牌，并且您不希望用户长时间保持身份验证。所以我认为你没有必要使用刷新令牌。
-
非常感谢 Tiny 的回答。我的产品有 10 个客户，对于所有客户，我将 refresh_token 及其哈希值保存在一个表中。但是，对于这个客户，他们需要 SSO 并且他们已经实施了 Free Pass AD。所以这限制了我的操作，因此我不得不走这条捷径。我喜欢你的解释。很清楚。再次感谢您:)
-
感谢您的回复和同意。我会发表我的评论作为答案，如果您觉得它对您有一点帮助，您可以选择它作为答案吗？非常感谢。
标签： azure-active-directory identityserver4 openid-connect access-token refresh-token