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?
当前回答
首先,客户端通过给予授权授权与授权服务器进行身份验证。然后,客户端通过提供访问令牌向资源服务器请求受保护的资源。资源服务器验证访问令牌并提供受保护的资源。客户端通过授予访问令牌向资源服务器发出受保护的资源请求,如果有效,资源服务器将在其中验证该请求并为请求提供服务。此步骤一直重复,直到访问令牌过期。如果访问令牌过期,则客户端向授权服务器进行身份验证,并通过提供刷新令牌来请求新的访问令牌。如果访问令牌无效,资源服务器将向客户端发回无效令牌错误响应。客户端通过授予刷新令牌与授权服务器进行身份验证。然后,授权服务器通过验证客户端来验证刷新令牌,并发出新的访问令牌(如果有效)。
其他回答
而刷新令牌由授权服务器保留。访问令牌是自包含的,因此资源服务器可以在不存储它的情况下对其进行验证,从而节省了验证时的检索工作。讨论中缺少的另一点来自rfc6749#page-55
“例如,授权服务器可以使用刷新令牌每次访问都会发出新的刷新令牌的循环令牌刷新响应。上一个刷新令牌无效,但由授权服务器保留。如果刷新令牌为攻击者和合法客户端,其中一个将显示无效的刷新令牌,该令牌将通知授权服务器违规。"
我认为使用刷新令牌的关键在于,即使攻击者设法获得了刷新令牌、客户端ID和秘密组合。如果每次刷新请求都会产生新的访问令牌和刷新令牌,则可以通过后续调用从攻击者处获取新的访问标志。
Catchdave提供的讨论链接还有Dick Hardt提出的另一个有效的观点(原始的,死链接),我认为除了上面写的内容之外,这里还值得一提:
我记得刷新令牌是为了安全和撤销。<...>撤销:如果访问令牌是自包含的,则可以通过不发布新的访问令牌来撤销授权。资源不需要查询授权服务器以查看访问令牌是否有效。这简化了访问令牌验证,并使扩展和支持多个授权服务器更加容易。当访问令牌有效但授权被撤销时,有一个时间窗口。
事实上,在资源服务器和授权服务器是同一个实体的情况下,并且用户和其中任何一个之间的连接(通常)都是同样安全的,那么将刷新令牌与访问令牌分开并没有多大意义。
尽管如引用中所述,刷新令牌的另一个作用是确保用户可以随时(例如通过其配置文件中的web界面)撤销访问令牌,同时保持系统的可伸缩性。
通常,令牌可以是指向服务器数据库中特定记录的随机标识符,也可以包含自身的所有信息(当然,这些信息必须使用MAC进行签名)。
具有长期访问令牌的系统应该如何工作
服务器允许客户端通过发出令牌访问预定义范围内的用户数据。由于我们希望保持令牌的可撤销性,我们必须在数据库中存储令牌以及设置或取消设置的标志“已撤销”(否则,如何使用自包含令牌?)。数据库可以包含多达len(用户)x len(注册客户端)x len(范围组合)的记录。然后,每个API请求都必须命中数据库。虽然对执行O(1)的数据库进行查询非常简单,但单点故障本身可能会对系统的可伸缩性和性能产生负面影响。
具有长期刷新令牌和短期访问令牌的系统应该如何工作
在这里,我们发布两个密钥:带有数据库中相应记录的随机刷新令牌,以及签名的自包含访问令牌,其中包含过期时间戳字段。
由于访问令牌是自包含的,因此我们根本不必访问数据库来检查其有效性。我们所要做的就是解码令牌并验证签名和时间戳。
尽管如此,我们仍然需要保留刷新令牌的数据库,但对该数据库的请求数量通常由访问令牌的寿命定义(寿命越长,访问率越低)。
为了撤销特定用户对客户端的访问,我们应该将相应的刷新令牌标记为“已撤销”(或完全删除),并停止发布新的访问令牌。很明显,在一个窗口中,刷新令牌已被撤销,但其访问令牌可能仍然有效。
权衡取舍
刷新令牌部分消除了访问令牌数据库的SPoF(单点故障),但它们有一些明显的缺点。
“窗口”。事件“用户撤销访问”和“保证撤销访问”之间的时间间隔。客户端逻辑的复杂性。无刷新令牌使用访问令牌发送API请求如果访问令牌无效,则失败并要求用户重新验证带刷新令牌使用访问令牌发送API请求如果访问令牌无效,请尝试使用刷新令牌更新它如果刷新请求通过,则更新访问令牌并重新发送初始API请求如果刷新请求失败,请要求用户重新验证
我希望这个答案确实有意义,有助于某人做出更深思熟虑的决定。我还想指出,一些著名的OAuth2提供商,包括github和foursquare,采用了没有刷新令牌的协议,并对此感到满意。
让我们考虑一个系统,其中每个用户链接到一个或多个角色,每个角色链接到一种或多种访问权限。可以缓存这些信息以获得更好的API性能。但是,用户和角色配置可能会发生变化(例如,可能会授予新的访问权限,或者可能会撤销当前的访问权限),这些都应该反映在缓存中。
我们可以为此目的使用访问和刷新令牌。当使用访问令牌调用API时,资源服务器检查缓存的访问权限。如果有任何新的访问许可,则不会立即反映。一旦访问令牌过期(例如在30分钟内)并且客户端使用刷新令牌生成新的访问令牌,就可以使用来自DB的更新的用户访问权限信息来更新缓存。
换句话说,我们可以将昂贵的操作从使用访问令牌的每次API调用转移到使用刷新令牌生成访问令牌的事件。
这些答案都没有找到刷新令牌存在的核心原因。显然,您总是可以通过将客户端凭据发送到身份验证服务器来获得新的访问令牌/刷新令牌对——这就是您首先获得它们的方式。
因此,刷新令牌的唯一目的是限制通过网络发送到身份验证服务的客户端凭据的使用。访问令牌的TTL越短,就越需要使用客户端凭据来获取新的访问令牌,因此攻击者就越有机会破坏客户端凭据(尽管如果使用非对称加密发送客户端凭据,这可能非常困难)。因此,如果您有一个一次性刷新令牌,您可以使访问令牌的TTL任意小,而不影响客户端凭据。
尽管上面的答案很好,但我作为一名安全硕士生和程序员,在研究买家保护和欺诈时,曾在eBay工作过,可以说,将访问令牌和刷新令牌分开,在骚扰频繁输入用户名/密码的用户和保留撤销对可能滥用您服务的访问权限之间取得了最佳平衡。
想象一下这样的情景。您向用户发出3600秒的访问令牌,刷新令牌的时间长达一天。
用户是一个好用户,他在家里,上下你的网站,在他的iPhone上购物和搜索。他的IP地址不会改变,并且服务器负载很低。像每分钟3-5页的请求。当他在访问令牌上的3600秒结束时,他需要一个具有刷新令牌的新令牌。在服务器端,我们检查他的活动历史和IP地址,认为他是一个人,行为举止得体。我们授予他一个新的访问令牌以继续使用我们的服务。用户不需要再次输入用户名/密码,直到达到刷新令牌本身的一天寿命。用户是一个粗心大意的用户。他住在美国纽约,病毒程序被关闭,在波兰被黑客入侵。当黑客获得访问令牌和刷新令牌时,他试图模拟用户并使用我们的服务。但是,在短暂的实时访问令牌过期后,当黑客试图刷新访问令牌时,我们在服务器上注意到用户行为历史中的IP发生了巨大变化(嘿,这家伙在美国登录,现在在波兰仅3600秒后刷新访问)。我们终止刷新过程,使刷新令牌本身无效,并提示再次输入用户名/密码。该用户是恶意用户。他打算通过使用机器人每分钟调用1000次我们的API来滥用我们的服务。直到3600秒后,当他试图刷新访问令牌时,我们注意到他的行为,认为他可能不是人类。我们拒绝并终止刷新过程,并要求他再次输入用户名/密码。这可能会破坏他的机器人的自动流动。至少让他不舒服。
当我们试图平衡我们的工作、用户体验和被盗令牌的潜在风险时,您可以看到刷新令牌的表现非常完美。服务器端的看门狗不仅可以检查IP更改,还可以检查api调用的频率,以确定用户是否应该是一个好用户。
另一个词是,您还可以尝试通过在每个api调用上实现基本IP看门狗或任何其他措施来限制被盗令牌/滥用服务的损害控制。但这很昂贵,因为您必须读取和写入有关用户的记录,并且会降低服务器响应速度。