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?
当前回答
由于刷新和访问令牌是加载了大量语义的术语,因此术语转换可能会有所帮助?
可撤销令牌-必须通过授权服务器检查的令牌可以链接(请参阅RTR-刷新令牌循环)可以用于创建不可撤销的令牌,但也可以直接使用(当卷很小且检查不会成为负担时)可以使用很长时间,但这取决于用户需要多久才能获得新的凭据(用户名/密码)可以在RTR或任何其他可疑行为上无效不可撤销令牌-自包含的令牌,不需要通过授权服务器进行检查适用于大数据、分布式服务器/api调用的横向扩展应该是短暂的(因为是不可撤销的)
2020年,浏览器中也可以存在刷新令牌(最初为后端系统提供),这一点已被接受-请参见https://pragmaticwebsecurity.com/articles/oauthoidc/refresh-token-protection-implications.因此,焦点从“可刷新性”(在没有用户的情况下,后端如何延长对api的访问)转向了“可撤销性”。
因此,在我看来,将刷新令牌读取为可撤销令牌并将访问令牌读取为不可撤销令牌(可能是快速过期不可撤销的令牌)看起来更安全。
作为2021良好实践的附带说明,系统始终可以从可撤销的令牌开始,并在授权服务器压力增加时转向不可撤销的。
其他回答
为了理解这个问题的答案,我们需要了解两点。
第一点是,有时用户的访问令牌可能会在用户不知情的情况下被盗。由于用户不知道攻击,他们将无法手动通知我们。然后,就我们给攻击者完成攻击的时间(机会)而言,15分钟和一整天之间会有巨大的差异。因此,这就是我们需要每“短时间”(例如,每15分钟)“刷新”访问令牌的原因,我们不想将此操作推迟很长时间(例如,一整天)。因此,OP在问题中所说的显然不是一个选项(将访问令牌的到期时间延长到刷新令牌的有效时间)。
因此,我们至少还有以下两个选择:
要求每个用户每隔一段时间重新输入他们的凭据,以便为他们提供新的访问令牌。但显然,这不是一个流行的选项,因为它会困扰用户。使用刷新令牌。阅读下面的第二点,以了解其工作原理(背后的逻辑)。
第二点需要理解的是,因为我们已经将访问令牌与刷新令牌分开,现在可以以“不同的方式”发送刷新令牌,因此我们可以以攻击者的JavaScript(通常是客户端代码)无法访问的方式发送它,例如,使用httpOnly标记:
HttpOnly Cookie是添加到浏览器Cookie中的标记,用于阻止客户端脚本访问数据。来源
在生成cookie时使用HttpOnly标志有助于降低客户端脚本访问受保护cookie的风险。HttpOnly cookie于2002年由Microsoft Internet Explorer开发人员针对Internet Explorer 6 SP1首次实现。来源(感谢IE!)
因此,尽管攻击者仍然可以窃取访问令牌(强烈建议将其保存在RAM中,而不是本地存储等易受攻击的地方),但他们将无法窃取刷新令牌。因此,如果攻击者窃取了一个人的访问令牌,他们只有很短的时间滥用它(15分钟?比一整天好得多!),然后一旦它过期,他们就没有机会自己获得新的令牌。
刷新令牌的思想是,如果访问令牌因其短暂而受到破坏,攻击者可以在有限的窗口中滥用它。
刷新令牌(如果被破坏)是无用的,因为攻击者除了需要刷新令牌之外还需要客户端id和密码,以便获得访问令牌。
话虽如此,由于每次对授权服务器和资源服务器的调用都是通过SSL完成的,包括请求访问/刷新令牌时的原始客户端id和secret,因此我不确定访问令牌如何比长期刷新令牌和客户端id/secret组合更“不可妥协”。
当然,这与不同时控制授权服务器和资源服务器的实现不同。
这里有一个很好的线程,讨论了刷新令牌的使用:OAuth存档。
引用上述内容,讨论刷新令牌的安全目的:
刷新令牌。。。降低长期access_token泄漏的风险(在不安全的资源服务器上的日志文件中查询参数,测试版或编码不良的资源服务器应用程序,非https站点上的JS SDK客户端将access_toke放入cookie等)
这个答案是在两位高级开发人员(约翰·布莱顿和大卫·詹内斯)的帮助下得出的。
使用刷新令牌的主要原因是减少攻击面。
假设没有刷新键,让我们来看看这个示例:
一座大楼有80扇门。所有车门都用同一把钥匙打开。钥匙每30分钟更换一次。在30分钟结束时,我必须把旧钥匙交给钥匙制造商,并获得一把新钥匙。
如果我是黑客,拿到了你的钥匙,那么在30分钟结束后,我会把它快递给钥匙制造商,并获得一把新钥匙。无论换钥匙,我都能连续打开所有车门。
问:在这30分钟里,我有多少次破解钥匙的机会?每次你使用密钥时,我都有80次黑客攻击的机会(把这看作是发出网络请求并传递访问令牌以识别自己)。这是80倍的攻击面。
现在让我们来看看同一个例子,但这次我们假设有一个刷新键。
一座大楼有80扇门。所有车门都用同一把钥匙打开。钥匙每30分钟更换一次。要获取新密钥,我无法传递旧的访问令牌。我只能通过刷新键。
如果我是黑客并得到了你的密钥,我可以使用它30分钟,但在30分钟结束时,将它发送给密钥制作者没有任何价值。如果我这样做了,那么密钥制作者只会说“此令牌已过期。您需要刷新令牌。”为了能够扩展我的黑客攻击,我必须将信使黑客攻击给密钥制作者。信使有一个不同的密钥(将其视为刷新令牌)。
问题:在30分钟内,我有多少次违反刷新键的黑客攻击机会?80? 不,我只有一次黑客攻击机会。在这段时间里,快递员与钥匙制造商进行沟通。这是1X攻击面。我确实有80次破解钥匙的机会,但30分钟后就不行了。
服务器将根据凭证和JWT的签名(通常)验证访问令牌。
访问令牌泄漏是不好的,但一旦过期,它对攻击者不再有用。刷新令牌泄漏的情况要糟糕得多,但估计可能性较小。(我认为,刷新令牌泄漏的可能性是否比访问令牌泄漏的概率低得多,这是一个问题,但这就是想法。)
重点是访问令牌被添加到您发出的每个请求中,而刷新令牌仅在刷新流期间使用所以MITM看到代币的可能性很小
频率有助于攻击者。像SSL中的潜在安全漏洞、客户端中的潜在的安全漏洞以及服务器中潜在的安全缺陷等令人心碎的漏洞都使泄漏成为可能。
此外,如果授权服务器与处理其他客户端请求的应用服务器分离,那么该应用服务器将永远不会看到刷新令牌。它只会看到不会持续很久的访问令牌。
分隔有利于安全。
最后但并非最不重要的刷新令牌可以被旋转。意思是“每次客户端请求将刷新令牌交换为新的访问令牌时,都会返回新的刷新令牌”。随着刷新令牌的不断交换和失效,威胁降低。举个例子:令牌通常在TTL之后过期,通常是一小时。
刷新令牌并不总是,但通常会在使用时被撤销,并发出新的令牌。这意味着,如果您在检索新的刷新令牌时发生网络故障,那么下次发送该刷新令牌时,它将被视为已吊销,您必须登录。
有关旋转的更多信息,请参阅此处和此处
总结
降低频率分区令牌的轮换(更快的失效)和更精细的管理(过期时间或请求数量)。
所有这些都有助于减轻威胁
关于这个问题的另一个观点,请看这个令人敬畏的答案
刷新令牌与什么无关?
通过刷新令牌更新/撤销访问级别的能力是选择使用刷新令牌的一个副产品,否则独立访问令牌可能会被撤销,或在其过期时修改其访问级别,用户将获得新令牌
这些答案都没有找到刷新令牌存在的核心原因。显然,您总是可以通过将客户端凭据发送到身份验证服务器来获得新的访问令牌/刷新令牌对——这就是您首先获得它们的方式。
因此,刷新令牌的唯一目的是限制通过网络发送到身份验证服务的客户端凭据的使用。访问令牌的TTL越短,就越需要使用客户端凭据来获取新的访问令牌,因此攻击者就越有机会破坏客户端凭据(尽管如果使用非对称加密发送客户端凭据,这可能非常困难)。因此,如果您有一个一次性刷新令牌,您可以使访问令牌的TTL任意小,而不影响客户端凭据。
尽管上面的答案很好,但我作为一名安全硕士生和程序员,在研究买家保护和欺诈时,曾在eBay工作过,可以说,将访问令牌和刷新令牌分开,在骚扰频繁输入用户名/密码的用户和保留撤销对可能滥用您服务的访问权限之间取得了最佳平衡。
想象一下这样的情景。您向用户发出3600秒的访问令牌,刷新令牌的时间长达一天。
用户是一个好用户,他在家里,上下你的网站,在他的iPhone上购物和搜索。他的IP地址不会改变,并且服务器负载很低。像每分钟3-5页的请求。当他在访问令牌上的3600秒结束时,他需要一个具有刷新令牌的新令牌。在服务器端,我们检查他的活动历史和IP地址,认为他是一个人,行为举止得体。我们授予他一个新的访问令牌以继续使用我们的服务。用户不需要再次输入用户名/密码,直到达到刷新令牌本身的一天寿命。用户是一个粗心大意的用户。他住在美国纽约,病毒程序被关闭,在波兰被黑客入侵。当黑客获得访问令牌和刷新令牌时,他试图模拟用户并使用我们的服务。但是,在短暂的实时访问令牌过期后,当黑客试图刷新访问令牌时,我们在服务器上注意到用户行为历史中的IP发生了巨大变化(嘿,这家伙在美国登录,现在在波兰仅3600秒后刷新访问)。我们终止刷新过程,使刷新令牌本身无效,并提示再次输入用户名/密码。该用户是恶意用户。他打算通过使用机器人每分钟调用1000次我们的API来滥用我们的服务。直到3600秒后,当他试图刷新访问令牌时,我们注意到他的行为,认为他可能不是人类。我们拒绝并终止刷新过程,并要求他再次输入用户名/密码。这可能会破坏他的机器人的自动流动。至少让他不舒服。
当我们试图平衡我们的工作、用户体验和被盗令牌的潜在风险时,您可以看到刷新令牌的表现非常完美。服务器端的看门狗不仅可以检查IP更改,还可以检查api调用的频率,以确定用户是否应该是一个好用户。
另一个词是,您还可以尝试通过在每个api调用上实现基本IP看门狗或任何其他措施来限制被盗令牌/滥用服务的损害控制。但这很昂贵,因为您必须读取和写入有关用户的记录,并且会降低服务器响应速度。