在线应用程序需要刷新令牌
根据Google的文档,看起来刷新令牌仅适用于离线应用程序(当用户不在时可能遇到过期访问令牌的应用程序)。
访问令牌定期到期。 如果您请求对与令牌关联的范围的离线访问,您可以刷新访问令牌而不提示用户授予权限(包括用户不在场时)。
...
当用户不在场时,请求离线访问是需要访问Google API的任何应用程序的要求。 例如,执行备份服务或在预定时间执行操作的应用程序需要能够在用户不在场时刷新其访问令牌。 默认的访问风格在线调用。
然而,一般来说刷新令牌的描述,尤其是这个问题似乎都暗示了,只要你想要一个新的访问令牌,就需要刷新令牌。
我想我会同意谷歌的解释,而不是使用刷新标记。 我与OIDC提供商的经验是刷新工作如下:
用户可能会看到一些重定向,但除此之外重新认证没有任何交互。 鉴于此,如果用户总是出现在应用程序中,是否有必要打扰刷新令牌?
不,如果用户总是出现在应用程序中,则没有必要打扰刷新令牌。 推理在很大程度上是OP描述的。
但是为什么人们仍然想要一个刷新标记是有原因的:
设想一种场景,您希望使用访问令牌几乎实时地从用户信息端点更新用户信息,但访问令牌过期相对较短。 要么你必须按照描述的方式执行大量的重定向,或者你可以使用刷新令牌。
使用在线应用程序刷新令牌的最大问题是,它会消除用户的透明度 。
刷新令牌有助于长期访问,应该安全地存储。 但是他们也没有提供一种自然的方式来“退出”,并且(最重要的),它是如何,何时以及从何处访问数据变得完全不透明的,正如经常使用的作用域名称offline_access
暗示的。
OIDC提供了一个前置通道机制, prompt=none
很大程度上导致相同的效果(即新令牌),并且如果在iframe内执行重新认证,则不需要中间重定向。
因此,我认为你和谷歌是对的,答案必须是:不,如果用户在场,不要使用刷新标记。
刷新令牌本质上是凭证引用,当没有活动的用户会话时,客户端可以交换访问令牌。 例如,如果您想定期将Github的问题与您的内部系统同步。
它经常被滥用,像某种会话。 对这些东西进行区分是非常重要的。 而范围名称offline_access是有原因的。
所以在简单的情况下 - 您只需依靠OP会话并获得带有授权/令牌端点组合的新令牌。 只要会话处于活动状态,并且已经为该特定应用程序提供了许可,就不应提示您提供凭据。
如果你需要做一些背景的东西 - 也要求刷新令牌。
至于问题:不。
编辑(更深入的解释):如果我们正在谈论网络,有两种主要情况:客户端可以安全地存储秘密,像通常的Web应用程序与服务器页面呈现和客户端,不能存储秘密,如SPA应用程序。 从这个角度来看,有两个主要流程(省略混合而不过分复杂):授权代码流和隐式流。
授权码流程
首先请求您的应用程序检查自己的会话(客户端会话),如果没有 - 重定向到外部OP(OpenID Connect提供程序)授权url。 OP根据要求中表达的要求验证用户,收集同意书和其他资料并返回授权码。 然后客户端向它询问令牌端点,并在用户授予脱机访问许可时接收带有可选刷新令牌的access_token / id_token对。 这很重要,因为用户可以为你的应用程序拒绝它。 此客户端可以请求userInfo端点获取同意期间授予的所有用户声明。 这些声明代表用户身份,并且不包含身份验证方法,acr等。这些声明以id_token的形式出现,例如过期。 在客户端启动它自己的会话后,可以选择将其生存期设置为等于id_token生存期,或者使用它自己来提供平滑的UX。 此时,如果您不需要访问其他API(如access_token中的所有范围都针对OP和主题),则可以放弃access_token和id_token。 如果您需要访问某些API,则可以存储access_token并将其用于访问。 它变得无效 - 重定向到新的OP。 因为服务器上更安全的环境,到期可能会更加松懈。 所以即使1小时也是一种选择。 根本没有刷新令牌。
隐式流程
在这种情况下,您可以说Angular应用程序重定向到OP,直接从授权端点获取其id_token和可选的access_token,并使用它访问一些API。 在每个请求中检查过期是否需要,客户端向隐藏的iFrame中的OP发送请求,因此只要OP会话处于活动状态,就不会有任何可见的重定向。 像openid-client.js有一些很好的库。 根本不允许刷新。
区分客户端会话与OP会话,令牌生存期和会话生存期很重要。
为了解决一些特定的需求,有Hybrid Flow。 它可以用于在一个请求中为您的会话获取授权代码和id_token。 无需通过网络聊天。
所以当你考虑刷新令牌时,只需检查你的需求并将它们映射到规范:)如果你仍然需要它 - 尽可能安全地存储它。
链接地址: http://www.djcxy.com/p/47947.html