我对在线应用程序使用刷新令牌最大的担忧是它会从用户那里夺走透明度。
刷新令牌便于长期访问，应安全存储。但是它们也没有提供一种自然的“注销”方式，并且（最重要的是）它变得完全不透明，如何，何时以及从何处访问您的数据，正如经常使用的范围名称offline_access所暗示的那样。
OIDC提供了一个前置通道机制prompt=none，在很大程度上导致相同的效果（即新令牌），并且如果在iframe内执行重新认证，则不需要中间重定向。
所以我认为你和谷歌是对的，答案应该是：否，如果用户在场，请勿使用刷新令牌。

不需要，如果用户总是出现在应用程序中，就没有必要为刷新令牌而烦恼。推理在很大程度上是OP描述的。
但是仍然需要刷新令牌的原因如下：

• 正如OP提到的，用户可能会看到一些重定向，UIMaven和团队中的品牌设计人员都会讨厌这种情况
• 当访问令牌在HTML表单POST动作的中间到期时，重定向可能在返回时丢失了上下文/POST数据;您可能希望最小化此问题，或者必须采取适当的（复杂的）POST数据保存操作
• 如果你的访问令牌的有效期很短，重定向会产生大量的开销和麻烦;当处理不同域中的提供程序时，您可能无法控制访问令牌到期，当处理多个提供程序时，它将因提供程序而异
• 当使用重定向刷新访问令牌时，您的应用程序现在依赖于保持SSO会话的提供程序;并非所有提供商都可以这样做，如果他们这样做，他们可以以不同的方式这样做：SSO会话持续时间可以在它们之间变化，并且认证方法可以变化;例如：不保留SSO会话但使用双因素身份验证的提供程序将对用户体验产生很大影响

设想这样一个场景：您希望使用访问令牌从用户信息端点几乎实时地更新用户信息，但访问令牌的到期时间相对较短。要么你必须执行大量的重定向与讨厌的描述，或者你可以使用刷新令牌。

刷新令牌本质上是一个凭据引用，当没有活动的用户会话时，您的客户端可以交换访问令牌。例如，如果你想定期将Github上的问题与你的内部系统同步。
它经常被滥用，就像某种会议一样。必须区分这些东西。作用域名称offline_access的存在是有原因的。
因此，在简单的情况下-您只需依赖OP会话并使用授权/令牌端点组合获得新令牌。只要会话处于活动状态并且已同意使用该特定应用程序，就不应提示您提供凭据。
如果你需要做一些后台的事情-也要求刷新令牌。
至于问题：不知道。

编辑（更深入的解释）：如果我们谈论Web，主要有两种情况：

客户端可以安全地存储秘密，如通常的Web应用程序与服务器页面渲染和客户端，不能存储秘密，如SPA应用程序。从这个Angular 来看，有两个主要的流程（省略混合以避免过于复杂）：授权代码流和隐式流。

授权码流程

在第一次请求时，您的应用会检查自己的会话（客户端会话），如果没有，则重定向到外部OP（OpenID Connect提供程序）授权URL。OP根据请求中表达的要求对用户进行身份验证，收集同意和其他内容，并返回授权代码。然后，客户端向令牌端点询问它，并在用户授予离线访问同意的情况下接收access_token/id_token对和可选的刷新令牌。这很重要，因为用户可以拒绝您的应用程序。在此之后，客户端可以请求userInfo端点获取在同意期间授予的所有用户声明。这些声明表示用户身份，不包含身份验证方法、acr等内容。例如，这些声明与expiration一起出现在id_token中。在此之后，客户端启动其自己的会话，并可以选择将其生命周期设置为等于id_token生命周期或使用其自己的来提供平滑的UX。此时，如果您不需要访问其他API，则可以完全放弃access_token和id_token（例如access_token中的所有作用域都特定于OP和subject）。如果您需要访问某些API，您可以存储access_token并使用它进行访问。它变得无效-重定向到OP以获得新的。由于服务器上的环境更安全，这里的过期可能更宽松。所以即使是1小时也是一种选择。根本没有使用刷新令牌。

隐式流

在这种情况下，假设Angular应用程序重定向到OP，直接从授权端点获取其id_token和可选的access_token，并使用它来访问一些API。在每个请求过期时，如果需要，客户端将请求发送到隐藏iFrame中的OP，因此只要OP会话处于活动状态，就不会有任何可见的重定向。有一些很棒的库，比如openid-client.js。这里根本不允许刷新。
区分客户端会话与OP会话、令牌生命周期和会话生命周期非常重要。
为了解决一些特定的需求，有混合流。它可以用于在一个请求中获取会话的授权码和id_token。不能通过网络聊天。
因此，当你考虑刷新令牌时，只需检查你的需求并将其Map到规范：）如果你无论如何都需要它-尽可能安全地存储它。

刷新令牌对于在服务器会话中保留访问令牌的应用程序很有用。例如，如果Web应用程序不使用JavaScript XHR调用受保护的服务，而是调用其后端，而后端调用该服务。在这种情况下，在需要时获取新的访问令牌比向用户请求新的访问令牌更容易。
在浏览器中运行的JavaScript应用程序中，不能使用刷新令牌，因为您需要一个客户端密钥才能从/token端点获取访问令牌，并且您无法在此类应用程序中保持密钥安全。
您描述的获取新访问令牌的过程可以改进-应用程序可能会在当前访问令牌到期之前要求新的访问令牌，因此用户不会被重定向到OAuth2服务器，但应用程序会在iframe中使用prompt=none参数调用/auth端点。