Skip to content

4.3. 刷新令牌许可

刷新令牌是授权服务器颁发给客户端的凭据,可以根据现有的授权,获取新的访问令牌。客户端使用该方法,要么是因为先前的访问令牌已过期,要么是因为客户端先前获得的访问令牌的范围比相应授权所批准的范围更窄,并且在同一授权下需要一个具有不同范围的访问令牌。

刷新令牌在传输和存储过程中必须保持机密,并且仅在授权服务器和被颁发该刷新令牌的客户端之间共享。授权服务器必须维护刷新令牌与被颁发该刷新令牌的客户端之间的绑定关系。

每当可以认证客户端时,授权服务器都必须验证刷新令牌与客户端身份的绑定。当无法认证客户端时,授权服务器应该颁发发送者约束的刷新令牌,或者使用刷新令牌轮换,如第 4.3.1 节所述。

授权服务器必须确保刷新令牌无法被未授权方生成、修改或猜中,来产生有效的刷新令牌。

4.3.1. 令牌端点扩展

在令牌端点上,该许可类型通过 grant_type 值为 refresh_token 来被标识。

如果设置了此值,那么以下这些在第 3.2.2 节描述之外的、额外的令牌请求参数也被支持:

“refresh_token”: 必需。颁发给客户端的刷新令牌。

“scope”: 可选。访问请求的范围,如第 1.4.1 节所述。请求范围禁止包含资源所有者的原授权中未包含的任何范围。如果省略,则视为与资源所有者的原授权的范围相等。

由于刷新令牌通常是用于请求额外访问令牌的长期凭据,因此刷新令牌与被颁发它的客户端绑定。机密客户端必须与授权服务器进行认证,如第 3.2.1 节所述。

例如,客户端使用 TLS 发起如下的 HTTP 请求(额外的换行符仅为展示目的):

http
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

除了第 3.2.2 节中的处理规则以外,授权服务器还必须

  • 如果请求中包含客户端认证信息,那么确保刷新令牌是颁发给该认证客户端的。或者,如果请求中包含 client_id,那么确保刷新令牌是颁发给相应客户端的。
  • 验证与该刷新令牌相应的授权是否仍然有效。
  • 验证刷新令牌的有效性。

授权服务器必须使用下列方法之一,来检测恶意参与者对公共客户端的刷新令牌重放攻击:

  • 发送者约束的刷新令牌: 授权服务器通过加密方法,将刷新令牌与特定的客户端实例绑定,例如使用 DPoP [RFC9449] 或 mTLS [RFC8705]。

刷新令牌轮换: 在每次访问令牌刷新响应中,授权服务器都颁发新的刷新令牌。先前的刷新令牌将被无效化,但是授权服务器将保留刷新令牌与客户端之间关系的信息。如果刷新令牌被泄露,并且随后被攻击者和合法客户端两者使用,那么其中一个将展示无效的刷新令牌,这也就会告知授权服务器存在违规行为。授权服务器无法确定哪一方提交了无效的刷新令牌,但它可以撤销活跃的刷新令牌,以及与之关联的访问权限授权许可。这样做可以阻止攻击,但也会迫使合法客户端获取新的授权许可。

实现时请注意,刷新令牌所属的许可可以被编码到刷新令牌本身中。这可以使得授权服务器高效地确定刷新令牌所属的授权,以及所有需要被撤销的刷新令牌,如扩展所述。在这种情况下,授权服务器必须确保刷新令牌值的完整性,例如使用签名。

4.3.2. 刷新令牌相应

如果有效且经过授权,授权服务器将颁发访问令牌,如第 3.2.3 节所述。

授权服务器可以发放一个新的刷新令牌,此时客户端必须丢弃旧的刷新令牌,并替换为新的刷新令牌。

4.3.3. 刷新令牌建议

在给客户端颁发新的刷新令牌后,授权服务器可以撤销旧的刷新令牌。如果颁发了新的刷新令牌,那么刷新令牌的范围必须与客户端在请求中包含的刷新令牌的范围一致。

在安全事故发生时,授权服务器可以自动撤销刷新令牌,例如:

  • 更改资源所有者密码
  • 在授权服务器上注销资源所有者

如果客户端在一段时间内处于非活动状态,即刷新令牌在一段时间内未被用于获取新的访问令牌,那么刷新令牌应该过期。刷新令牌的过期时间由授权服务器自行决定。这一时间可能是一个全局值,也可能根据客户端策略,或者根据与刷新令牌(及其敏感性)关联的许可来确定。

本站使用 Vitepress 构建