在线应用程序是否需要刷新令牌

Question

根据Google的文档,似乎只有脱机应用程序才需要刷新令牌(当用户不在时,可能会遇到过期访问令牌的应用程序).

访问令牌定期到期.如果您请求脱机访问与令牌关联的作用域,则可以刷新访问令牌而不提示用户获得权限(包括用户不存在时).

...

要求离线访问是任何需要在用户不在时访问Google API的应用程序的要求.例如,执行备份服务或在预定时间执行操作的应用程序需要能够在用户不在时刷新其访问令牌.默认访问方式称为在线.

但是,一般来说刷新令牌的描述以及特别是这个问题似乎都暗示,只要您想要请求新的访问令牌,就需要刷新令牌.

我想我会同意谷歌的解释,而不是使用刷新令牌.我对OIDC提供商的经验是,刷新的工作原理如下:

1. 用户向客户端服务器请求受保护资源
2. 客户端服务器确定访问令牌已过期.
3. 客户端服务器将用户重定向到OP auth端点
4. 由于使用OP的域存储在用户浏览器上的cookie,OP无需交互即可对用户进行身份验证.
5. 客户端服务器完成请求.

用户可能会看到一些重定向,但除了重新进行身份验证之外没有任何交互.鉴于此,如果用户总是出现在应用程序中,是否有必要使用刷新令牌？

Answer 1

不,如果用户总是出现在应用程序中,则无需使用刷新令牌.推理主要是OP描述的.

但是有理由可能仍然需要刷新令牌:

• 正如OP提到的那样,用户可能会看到一些重定向,而你的团队中的UI专家和品牌人都会讨厌这个
• 当访问令牌在HTML表单POST操作过程中到期时,重定向可能在返回时丢失了上下文/ POST数据; 您可能希望最小化此操作,或者您必须采取适当的(复杂的)POST数据保存操作
• 如果您的访问令牌到期时间非常短,则重定向会产生大量开销和麻烦; 在处理不同域中的提供商时,您可能无法控制访问令牌到期,并且在与多个提供商打交道时,它们会因它们而异
• 当使用重定向刷新访问令牌时,您的应用程序现在取决于提供者保持SSO会话; 并非所有提供商都可以这样做,如果他们这样做,他们可能会以不同的方式进行:SSO会话持续时间可能会有所不同,并且身份验证方法可能会有所不同; 例如:不保留SSO会话但使用双因素身份验证的提供商将对用户体验产生巨大影响

想象一下,您希望使用访问令牌几乎实时地从用户信息端点更新用户信息,但访问令牌到期时间相对较短.您要么必须执行大量的重定向,如上所述,或者您可以使用刷新令牌.

Answer 2

使用在线应用程序的刷新令牌时,我最担心的是它会剥夺用户的透明度.

刷新令牌有助于长期访问,应安全存储.但它们也没有提供一种"退出"的自然方式,而且(最重要的是)它的访问方式,时间和地点变得完全不透明,正如常用的范围名称所offline_access暗示的那样.

OIDC提供了一个prompt=none主要导致相同效果的前端通道机制(即新令牌),如果在iframe内执行重新身份验证,则不需要中间重定向.

因此,在我看来,你和谷歌是正确的,答案必须是:不,如果用户在场,不要使用刷新令牌.

Answer 3

刷新令牌对于在服务器会话中保留访问令牌的应用程序非常有用。例如，如果 Web 应用程序不使用 JavaScript XHR 调用受保护的服务，而是调用其后端，而后端则调用该服务。在这种情况下，在需要时获取新的访问令牌比向用户请求新的访问令牌更容易。

在浏览器中运行的 JavaScript 应用程序中，无法使用刷新令牌，因为您需要客户端密钥才能从端点获取访问令牌/token，并且无法在此类应用程序中保证密钥的安全。

您描述的获取新访问令牌的过程可以改进 - 应用程序可能会在当前访问令牌到期之前请求新的访问令牌，因此用户不会被重定向到 OAuth2 服务器，但应用程序会使用参数/auth调用prompt=none端点在 iframe 中。