授权码授权协议中的OAuth-2.0瓶颈

考虑OAuth-2.0授权码授权协议。授权码授权协议中的OAuth-2.0瓶颈

作为上Figure 3 : Authorization Code Flow一个Client在标准草案http://tools.ietf.org/html/ietf-oauth-v2-26描述越来越从User-Agent接收代表Authorization Code令牌。假设User-Agent是故意向Client发送错误代码。如果Authorization Server通过禁止Client一段合理的时间（通过IP或通过主机名称Redirection URI）获得brute force获得Access Token的一些保护。如果在我们的案例中，Client应该处理来自多个不同User-Agent's的请求，Client将停止为所有用户提供服务，如果只有一个恶意存在。

因此，Client成为上述情况的瓶颈。

==== EDITED ==== 任何想法如何避开瓶颈问题？

来源

2012-05-24 Artem Oboturov

我相信你会问：“怎么回避这个问题，而不是揭露授权码到用户代理”

这是不可能的。 OAuth请求流经用户的浏览器，因此您无法防止将授权码暴露给用户。

如果您是这种攻击的受害者，我建议将相同的保护措施放入您的客户端，以便OAuth提供商将其放入授权服务器。即，停止允许滥用您的服务的用户代理发送新的授权代码。如果他们每小时发送超过3个无效令牌，禁止他们一两个小时（通过IP地址）。当然，这可能会导致您拒绝从代理服务器访问您的网站，因为代理服务器上有一个不好的用户，但这就是生活。

来源

2012-05-25 17:47:55

这是关于'访问令牌'，但我们的情况是非常麻烦的，因为我们有义务使用Auth提供者实现的唯一一个Auth类型。我将删除关于'Auth Token'的短语，因为这是误导和抵消我的问题的一点。谢谢你的回答。 –

感谢您的澄清。尽管我认为响应保持不变 - 防止对您的客户端发起此攻击的唯一方法是实施与OAuth提供程序实施的相同类型的防护，以防止您的客户端被用于这些强力攻击。 –

如果您只是使用OAuth进行*授权*，并且用户已通过身份验证（例如通过用户名/密码），则可能需要先验证身份，然后再调用OAuth提供程序。然后，您可以限制每个已通过身份验证的用户的OAuth请求数量，并使用CAPTCHA或类似方法来增加用户创建的难度。基本上，你可以使机器更难使用你的服务 - 但可能不会使它变得不可能。在某些时候，攻击者可能会决定有更容易的目标，并让你独处，尽管:) –

授权码授权协议中的OAuth-2.0瓶颈

回答

相关问题