根据我的理解,为了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如何使用安全令牌防止重放攻击?


当前回答

图1,摘自RFC6750:

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

其他回答

OAuth是一种协议,第三方应用程序可以在不需要您的帐户和密码的情况下访问存储在另一个网站上的数据。有关更正式的定义,请参考Wiki或规范。

下面是一个用例演示:

我登录领英,想联系我Gmail联系人中的一些朋友。LinkedIn支持这一点。它将从gmail请求一个安全资源(我的gmail联系人列表)。我点击这个按钮: 弹出一个网页,它显示Gmail登录页面,当我输入我的帐户和密码: Gmail然后显示一个同意页面,我点击“接受”: 现在LinkedIn可以访问我在Gmail的联系人:

下面是上面例子的流程图:

步骤1:LinkedIn从Gmail的授权服务器请求一个令牌。

步骤2:Gmail授权服务器对资源所有者进行身份验证,并向用户显示同意页面。(如果用户尚未登录,则需要登录Gmail)

步骤3:用户授予LinkedIn访问Gmail数据的请求。

步骤4:Gmail授权服务器返回一个访问令牌。

步骤5:LinkedIn使用这个访问令牌调用Gmail API。

步骤6:如果访问令牌有效,Gmail资源服务器将返回您的联系人。(令牌将由Gmail资源服务器验证)

你可以在这里获得更多关于OAuth的细节。

这是一块宝石:

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查询参数…用于记录当前使用情况;它的用途不是 推荐,由于其安全性不足

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

这里可能是OAuth2如何为所有4种授权类型工作的最简单的解释,即应用程序可以获得访问令牌的4个不同的流。

相似

所有授权类型流都有两部分:

获取访问令牌 使用访问令牌

第二部分“使用访问令牌”对所有流程都是相同的

区别

每个授权类型的流的第一部分“获取访问令牌”各不相同。

然而,一般来说,“获取访问令牌”部分可以概括为5个步骤:

预先注册你的应用(客户端)与OAuth提供商,例如,Twitter等,以获得客户端id/秘密 在你的页面上创建一个带有客户端id和所需范围/权限的社交登录按钮,这样当点击用户时就会被重定向到OAuth提供者进行身份验证 OAuth提供商请求用户授予你的应用(客户端)权限 OAuth提供者发布代码 App(客户端)获取访问令牌

下面是一个并排的图表,比较了基于5个步骤的每个拨款类型流程的不同。

这个图表来自https://blog.oauth.io/introduction-oauth2-flow-diagrams/

每一个都有不同的实现难度、安全性和用例级别。根据您的需要和情况,您将不得不使用其中之一。用哪一种?

客户端凭证:如果你的应用程序只服务于一个用户

资源所有者密码凭据:这应该仅作为最后的手段,因为用户必须将他的凭据移交给应用程序,这意味着应用程序可以做用户所能做的一切

授权代码:获得用户授权的最佳方式

隐式:如果你的应用是移动应用或单页应用

这里有更多关于这个选择的解释:https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/