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?
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?
当前回答
刷新令牌的思想是,如果访问令牌因其短暂而受到破坏,攻击者可以在有限的窗口中滥用它。
刷新令牌(如果被破坏)是无用的,因为攻击者除了需要刷新令牌之外还需要客户端id和密码,以便获得访问令牌。
话虽如此,由于每次对授权服务器和资源服务器的调用都是通过SSL完成的,包括请求访问/刷新令牌时的原始客户端id和secret,因此我不确定访问令牌如何比长期刷新令牌和客户端id/secret组合更“不可妥协”。
当然,这与不同时控制授权服务器和资源服务器的实现不同。
这里有一个很好的线程,讨论了刷新令牌的使用:OAuth存档。
引用上述内容,讨论刷新令牌的安全目的:
刷新令牌。。。降低长期access_token泄漏的风险(在不安全的资源服务器上的日志文件中查询参数,测试版或编码不良的资源服务器应用程序,非https站点上的JS SDK客户端将access_toke放入cookie等)
其他回答
这个答案来自Justin Richer通过OAuth 2标准正文电子邮件列表。这是在他的许可下发布的。
刷新令牌的生命周期取决于(AS)授权服务器-它们可以过期、被撤销等。刷新令牌和访问令牌的区别在于受众:刷新令牌只返回授权服务器,访问令牌返回(RS)资源服务器。
此外,仅仅获得访问令牌并不意味着用户已经登录。事实上,用户可能已经不在那里了,这实际上是刷新令牌的预期用例。刷新访问令牌将允许您代表用户访问API,但不会告诉您用户是否在那里。
OpenIDConnect不仅从访问令牌提供用户信息,还提供ID令牌。这是一个单独的数据块,指向客户端本身,而不是AS或RS。在OIDC中,如果您可以获得一个新的ID令牌,您应该只考虑某人实际通过协议“登录”。刷新它可能还不够。
有关更多信息,请阅读http://oauth.net/articles/authentication/
为了消除一些混淆,您必须了解客户机密码和用户密码的角色,这两个角色非常不同。
客户端是应用程序/网站/程序/。。。,该服务器希望通过使用第三方身份验证服务对用户进行身份验证。客户端机密是一个(随机)字符串,该字符串对此客户端和身份验证服务器都是已知的。使用这个秘密,客户端可以通过身份验证服务器识别自己,从而获得请求访问令牌的授权。
要获取初始访问令牌和刷新令牌,需要:
用户ID用户密码客户端ID客户机密
要获取刷新的访问令牌,客户端使用以下信息:
客户端ID客户机密刷新令牌
这清楚地表明了区别:在刷新时,客户端通过使用其客户端密钥来获得刷新访问令牌的授权,因此可以使用刷新令牌而不是用户ID+密码来重新验证用户。这有效地防止了用户必须重新输入他/她的密码。
这也表明,丢失刷新令牌是没有问题的,因为客户机ID和机密是未知的。它还表明,保持客户机ID和客户机机密是至关重要的。
为了理解这个问题的答案,我们需要了解两点。
第一点是,有时用户的访问令牌可能会在用户不知情的情况下被盗。由于用户不知道攻击,他们将无法手动通知我们。然后,就我们给攻击者完成攻击的时间(机会)而言,15分钟和一整天之间会有巨大的差异。因此,这就是我们需要每“短时间”(例如,每15分钟)“刷新”访问令牌的原因,我们不想将此操作推迟很长时间(例如,一整天)。因此,OP在问题中所说的显然不是一个选项(将访问令牌的到期时间延长到刷新令牌的有效时间)。
因此,我们至少还有以下两个选择:
要求每个用户每隔一段时间重新输入他们的凭据,以便为他们提供新的访问令牌。但显然,这不是一个流行的选项,因为它会困扰用户。使用刷新令牌。阅读下面的第二点,以了解其工作原理(背后的逻辑)。
第二点需要理解的是,因为我们已经将访问令牌与刷新令牌分开,现在可以以“不同的方式”发送刷新令牌,因此我们可以以攻击者的JavaScript(通常是客户端代码)无法访问的方式发送它,例如,使用httpOnly标记:
HttpOnly Cookie是添加到浏览器Cookie中的标记,用于阻止客户端脚本访问数据。来源
在生成cookie时使用HttpOnly标志有助于降低客户端脚本访问受保护cookie的风险。HttpOnly cookie于2002年由Microsoft Internet Explorer开发人员针对Internet Explorer 6 SP1首次实现。来源(感谢IE!)
因此,尽管攻击者仍然可以窃取访问令牌(强烈建议将其保存在RAM中,而不是本地存储等易受攻击的地方),但他们将无法窃取刷新令牌。因此,如果攻击者窃取了一个人的访问令牌,他们只有很短的时间滥用它(15分钟?比一整天好得多!),然后一旦它过期,他们就没有机会自己获得新的令牌。
这一切都与扩展和保持资源服务器无状态有关。
您的服务器/资源服务器服务器是无状态的,这意味着不检查任何存储以快速响应。通过使用公钥验证令牌的签名来执行此操作。检查每个请求的access_token。通过只检查access_token的签名和过期日期,响应速度非常快,并允许扩展。access_token应该有很短的到期时间(几分钟),因为如果它被泄露,就没有办法撤销它。身份验证服务器/OAuth服务器服务器不是无状态的,但它可以,因为请求要少得多。仅在access_token过期时检查refresh_token。(例如每2分钟)请求速率远低于资源服务器。将刷新令牌存储在数据库中,并可以撤消它。refresh_token可能有很长的到期时间(几周/几个月),如果它被泄露,有办法撤销它。
不过有一个重要的注意事项,身份验证服务器的请求要少得多,因此可以处理负载,但是由于必须存储所有refresh_token,因此可能存在存储问题,如果用户急剧增加,这可能会成为一个问题。
让我们考虑一个系统,其中每个用户链接到一个或多个角色,每个角色链接到一种或多种访问权限。可以缓存这些信息以获得更好的API性能。但是,用户和角色配置可能会发生变化(例如,可能会授予新的访问权限,或者可能会撤销当前的访问权限),这些都应该反映在缓存中。
我们可以为此目的使用访问和刷新令牌。当使用访问令牌调用API时,资源服务器检查缓存的访问权限。如果有任何新的访问许可,则不会立即反映。一旦访问令牌过期(例如在30分钟内)并且客户端使用刷新令牌生成新的访问令牌,就可以使用来自DB的更新的用户访问权限信息来更新缓存。
换句话说,我们可以将昂贵的操作从使用访问令牌的每次API调用转移到使用刷新令牌生成访问令牌的事件。