根据我的理解，为了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如何使用安全令牌防止重放攻击?
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的细节。
这里可能是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/
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的细节。
根据我所读到的，它是这样运作的:
问题中概括的大致流程是正确的。在步骤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是行不通的，因为可能有许多未完成的访问令牌等待同时分发到不同的站点。
另一个答案非常详细，解决了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查询参数…用于记录当前使用情况;它的用途不是
推荐，由于其安全性不足
