OAuth 2.0协议草案的第4.2节指出,授权服务器可以返回access_token(用于通过资源验证自己)和refresh_token,refresh_taken纯粹用于创建新的access_token:

https://www.rfc-editor.org/rfc/rfc6749#section-4.2

为什么两者都有?为什么不让access_token和refresh_token一样长,而不设置refresh_taken?


当前回答

据我所知,如果您需要撤销访问,刷新令牌只是为了性能和成本节省。

例1:不实现刷新令牌;仅实现长期访问令牌:如果用户滥用服务(例如:不支付订阅),您需要能够撤销访问令牌=>您需要在每个需要访问令牌的API调用上检查访问令牌的有效性,这会很慢,因为它需要DB查找(缓存可以帮助,但这更复杂)。

例2:实现刷新令牌和短期访问令牌:如果用户滥用服务(例如:不支付订阅),您需要能够撤销访问令牌=>短暂的访问令牌将在短暂的白色(例如1小时)后过期,用户将需要获得新的访问令牌,因此我们不需要对需要访问令牌的每个API调用进行验证。您只需要在从刷新令牌生成访问令牌时验证用户。对于坏用户,如果无法生成访问令牌,则可以注销该用户。当用户尝试重新登录时,验证将再次运行并返回错误。

其他回答

为了消除一些混淆,您必须了解客户机密码和用户密码的角色,这两个角色非常不同。

客户端是应用程序/网站/程序/。。。,该服务器希望通过使用第三方身份验证服务对用户进行身份验证。客户端机密是一个(随机)字符串,该字符串对此客户端和身份验证服务器都是已知的。使用这个秘密,客户端可以通过身份验证服务器识别自己,从而获得请求访问令牌的授权。

要获取初始访问令牌和刷新令牌,需要:

用户ID用户密码客户端ID客户机密

要获取刷新的访问令牌,客户端使用以下信息:

客户端ID客户机密刷新令牌

这清楚地表明了区别:在刷新时,客户端通过使用其客户端密钥来获得刷新访问令牌的授权,因此可以使用刷新令牌而不是用户ID+密码来重新验证用户。这有效地防止了用户必须重新输入他/她的密码。

这也表明,丢失刷新令牌是没有问题的,因为客户机ID和机密是未知的。它还表明,保持客户机ID和客户机机密是至关重要的。

而刷新令牌由授权服务器保留。访问令牌是自包含的,因此资源服务器可以在不存储它的情况下对其进行验证,从而节省了验证时的检索工作。讨论中缺少的另一点来自rfc6749#page-55

“例如,授权服务器可以使用刷新令牌每次访问都会发出新的刷新令牌的循环令牌刷新响应。上一个刷新令牌无效,但由授权服务器保留。如果刷新令牌为攻击者和合法客户端,其中一个将显示无效的刷新令牌,该令牌将通知授权服务器违规。"

我认为使用刷新令牌的关键在于,即使攻击者设法获得了刷新令牌、客户端ID和秘密组合。如果每次刷新请求都会产生新的访问令牌和刷新令牌,则可以通过后续调用从攻击者处获取新的访问标志。

客户可以通过多种方式受到损害。例如,可以克隆手机。访问令牌过期意味着客户端被迫重新向授权服务器进行身份验证。在重新认证期间,授权服务器可以检查其他特征(IOW执行自适应访问管理)。

刷新令牌允许仅客户端进行重新身份验证,其中重新授权会强制与用户进行对话,许多用户表示他们不愿意这样做。

刷新令牌基本上适用于正常网站可能选择在一小时左右后定期重新验证用户的相同位置(例如银行网站)。由于大多数社交网站都不会重新验证网络用户,因此目前它的使用率并不高,那么他们为什么要重新验证客户端呢?

由于刷新和访问令牌是加载了大量语义的术语,因此术语转换可能会有所帮助?

可撤销令牌-必须通过授权服务器检查的令牌可以链接(请参阅RTR-刷新令牌循环)可以用于创建不可撤销的令牌,但也可以直接使用(当卷很小且检查不会成为负担时)可以使用很长时间,但这取决于用户需要多久才能获得新的凭据(用户名/密码)可以在RTR或任何其他可疑行为上无效不可撤销令牌-自包含的令牌,不需要通过授权服务器进行检查适用于大数据、分布式服务器/api调用的横向扩展应该是短暂的(因为是不可撤销的)


2020年,浏览器中也可以存在刷新令牌(最初为后端系统提供),这一点已被接受-请参见https://pragmaticwebsecurity.com/articles/oauthoidc/refresh-token-protection-implications.因此,焦点从“可刷新性”(在没有用户的情况下,后端如何延长对api的访问)转向了“可撤销性”。

因此,在我看来,将刷新令牌读取为可撤销令牌并将访问令牌读取为不可撤销令牌(可能是快速过期不可撤销的令牌)看起来更安全。

作为2021良好实践的附带说明,系统始终可以从可撤销的令牌开始,并在授权服务器压力增加时转向不可撤销的。

首先,客户端通过给予授权授权与授权服务器进行身份验证。然后,客户端通过提供访问令牌向资源服务器请求受保护的资源。资源服务器验证访问令牌并提供受保护的资源。客户端通过授予访问令牌向资源服务器发出受保护的资源请求,如果有效,资源服务器将在其中验证该请求并为请求提供服务。此步骤一直重复,直到访问令牌过期。如果访问令牌过期,则客户端向授权服务器进行身份验证,并通过提供刷新令牌来请求新的访问令牌。如果访问令牌无效,资源服务器将向客户端发回无效令牌错误响应。客户端通过授予刷新令牌与授权服务器进行身份验证。然后,授权服务器通过验证客户端来验证刷新令牌,并发出新的访问令牌(如果有效)。