根据我的理解,为了Site-A从Site-B访问用户的信息,OAuth 2中发生了以下一系列事件。

Site-A registers on Site-B, and obtains a Secret and an ID. When User tells Site-A to access Site-B, User is sent to Site-B where they tell Site-B that they would indeed like to give Site-A permissions to specific information. Site-B redirects User back to Site-A, along with an Authorization Code. Site-A then passes that Authorization Code along with its Secret back to Site-B in return for a Security Token. Site-A then makes requests to Site-B on behalf of User by bundling the Security Token along with requests.

在高水平上,所有这些在安全和加密方面是如何工作的?OAuth 2如何使用安全令牌防止重放攻击?


当前回答

OAuth2本身并不能保护您免受重放攻击。但是,可以使用MTLS或DPoP等“扩展”。你可以在https://marcinjahn.com/technologies/security/oauth2/sender-constraint.html上找到更多信息

其他回答

根据我所读到的,它是这样运作的:

问题中概括的大致流程是正确的。在步骤2中,用户X经过身份验证,并授权站点A访问站点B上的用户X的信息。在步骤4中,站点将其Secret传递回站点B,验证自身以及授权码,表明它正在请求什么(用户X的访问令牌)。

总的来说,OAuth 2实际上是一个非常简单的安全模型,加密从未直接发挥作用。相反,Secret和Security Token本质上都是密码,整个事情仅由https连接的安全性保护。

OAuth 2没有针对安全令牌或秘密的重放攻击的保护。相反,它完全依赖于站点B负责这些项目,不让它们流出,并在传输过程中通过https发送(https将保护URL参数)。

授权码步骤的目的只是为了方便,而授权码本身并不是特别敏感。当向站点B请求用户X的访问令牌时,它为站点a的用户X的访问令牌提供了一个公共标识符。仅在站点B上使用用户X的用户id是行不通的,因为可能有许多未完成的访问令牌等待同时分发到不同的站点。

这是一块宝石:

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

非常简短的总结:

OAuth定义了四个角色:

资源所有者 客户端 资源服务器 授权服务器

您(资源所有者)有一部手机。你有几个不同的电子邮件帐户,但你希望所有的电子邮件帐户都在一个应用程序中,所以你不需要一直切换。因此,您的GMail(客户端)要求访问(通过雅虎的授权服务器)到您的雅虎电子邮件(资源服务器),以便您可以在GMail应用程序上阅读这两封电子邮件。

OAuth存在的原因是GMail存储您的Yahoo用户名和密码是不安全的。

另一个答案非常详细,解决了OP提出的大部分问题。

为了详细说明,特别是解决OP的问题“OAuth 2如何防止使用安全令牌的重放攻击?”,在实现OAuth 2的官方建议中有两个额外的保护措施:

令牌通常有一个很短的有效期(https://www.rfc-editor.org/rfc/rfc6819#section-5.1.5.3):

令牌的短到期时间是一种保护手段 以下威胁: 重播…

站点A使用令牌时,建议它不作为URL参数,而是在授权请求报头字段(https://www.rfc-editor.org/rfc/rfc6750):)中显示

客户端应该使用承载令牌进行身份验证请求 “授权”请求头字段与“承载”HTTP 授权方案。 ... 不应该使用"application/x-www-form-urlencoded"方法 除非在应用程序上下文中,其中参与的浏览器不这样做 可以访问“授权”请求头字段。 ... URI查询参数…用于记录当前使用情况;它的用途不是 推荐,由于其安全性不足

这就是Oauth 2.0的工作原理,本文对此进行了详细解释

OAuth2本身并不能保护您免受重放攻击。但是,可以使用MTLS或DPoP等“扩展”。你可以在https://marcinjahn.com/technologies/security/oauth2/sender-constraint.html上找到更多信息