OAuth 2如何使用安全性令牌防范诸如重播攻击之类的事情？

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

1. Site-A在上注册Site-B，并获取密钥和ID。
2. 当用户告诉Site-A访问Site-B，用户发送给Site-B他们讲Site-B，他们的确会想给Site-A权限的具体信息。
3. Site-B将用户Site-A以及授权码重定向回。
4. Site-A然后将该授权码及其秘密传递回以Site-B换取安全令牌。
5. Site-A然后将安全令牌与请求捆绑在一起Site-B，代表用户发出请求。

从安全性和加密的角度来看，所有这些工作如何运作？OAuth 2如何使用安全性令牌防范诸如重播攻击之类的事情？

OAuth 2.0在现实生活中的工作方式：

当我上班的时候，我在车道上开车去看Olaf的面包店时，看到窗户上最美味的甜甜圈-我的意思是，那东西滴满了巧克力般的美味。所以我走进去，要求“我必须吃那个甜甜圈！”。他说，“确定将是30美元。”

是的，我知道，一个甜甜圈要30美元！一定很好吃！我突然拿起钱包，突然听到厨师大喊“不！不给你甜甜圈”。我问：为什么？他说他只接受银行转帐。

认真吗 是的，他是认真的。我差点就走到那儿，但是甜甜圈呼唤我：“吃了，我很好吃……”。我要服从甜甜圈的命令是谁？我说了可以。

他递给我一张便条，上面写着他的名字（厨师，不是甜甜圈）：“告诉他们奥拉夫给你发来的信”。他的名字已经在笔记中了，所以我不知道那是什么意思，但是还可以。

我开车去了一个半小时。我把纸条交给了出纳员。我告诉她奥拉夫送我了。她给了我其中一种表情，说：“我会读”。

她记下我的钞票，问我的身份证，问我可以给他多少钱。我告诉她30美元。她做了些涂鸦，并递给我另一张纸条。这上面有很多数字，我想这就是他们记录笔记的方式。

那时候我饿了。我冲出那里，一个半小时后，我回来了，站在奥拉夫的面前，张开了我的纸条。他拿着它，看了一眼，说：“我会回来的”。

我以为他要吃甜甜圈了，但是30分钟后我开始变得可疑了。所以我问柜台后面的那个人：“奥拉夫在哪里？”。他说：“他去赚钱”。“你什么意思？”。“他记钱到银行”。

呵呵...奥拉夫（Olaf）注意到银行给了我，然后又回到银行从我的帐户中取钱。既然他有了银行给我的钞票，银行就知道他是我在说的那个人，而且因为我和银行谈话，他们知道只给他30美元。

我一定花了很长时间才弄清楚，因为当我抬起头来时，奥拉夫站在我面前终于把甜甜圈递给我。在我离开之前，我不得不问：“奥拉夫，你总是这样卖甜甜圈吗？”。“不，我曾经做过不同的事情。”

嗯 当我回到车上时，手机响了。我没有理会，可能是我的工作要求开除我，我的老板真是个***。此外，我还想着刚刚经历的过程。

我的意思是考虑一下：我能够让Olaf从我的银行帐户中取出30美元，而不必向他提供我的帐户信息。而且我不必担心他会掏出太多钱，因为我已经告诉银行只允许他收取30美元。银行知道他是正确的人，因为他得到了他们给我的给奥拉夫的钞票。

好吧，确定我会从口袋里递给他30美元。但是既然他有了那张纸条，我就可以告诉银行让他每周拿走30美元，然后我就可以在面包店露面，而不必再去银行了。如果愿意，我什至可以通过电话订购甜甜圈。

当然，我永远不会那样做-甜甜圈真令人恶心。

我想知道这种方法是否具有更广泛的应用。他提到这是他的第二种方法，我可以称其为Olaf 2.0。无论如何，我最好回到家，我必须开始寻找新工作。但是，在我从整个城市的新地方买到一种草莓奶昔之前，我需要一些东西来冲走那种甜甜圈的味道。

根据我所读的内容，这就是全部的工作方式：

问题中概述的一般流程是正确的。在步骤2中，对用户X进行身份验证，并且还授权站点A访问站点B上用户X的信息。在步骤4中，站点将其秘密传递回站点B，以对其进行身份验证以及授权码，从而指示出它要求（用户X的访问令牌）。

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

OAuth 2没有针对安全令牌或密钥的重放攻击的保护措施。取而代之的是，它完全依赖于站点B对这些项目负责，而不是让它们离开，并且在传输过程中通过https发送它们（https将保护URL参数）。

授权代码步骤的目的仅仅是为了方便，并且授权代码本身并不特别敏感。当向站点B询问用户X的访问令牌时，它为站点A的用户X的访问令牌提供了通用标识符。站点B上仅用户X的用户ID将无法正常工作，因为可能有许多未完成的访问令牌等待同时分发给其他站点。

OAuth是一种协议，三方应用可以使用该协议访问您存储在另一个网站中的数据，而无需使用您的帐户和密码。有关更正式的定义，请参阅Wiki或规范。

这是一个用例演示：

1. 我登录到LinkedIn，并希望与我的Gmail联系人中的一些朋友建立联系。LinkedIn支持这一点。它将从gmail请求安全资源（我的gmail联系人列表）。所以我点击这个按钮：
   

2. 输入我的帐户和密码后，将弹出一个网页，并显示Gmail登录页面：
   

3. 然后，Gmail会显示一个同意页面，我单击“接受”：

4. 现在，LinkedIn可以在Gmail中访问我的联系人：

下面是上面示例的流程图：

步骤1：LinkedIn向Gmail的授权服务器请求令牌。

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

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

步骤4：Gmail授权服务器以访问令牌作为响应。

步骤5：LinkedIn使用此访问令牌调用Gmail API。

步骤6：如果访问令牌有效，则Gmail资源服务器将返回您的联系人。（令牌将由Gmail资源服务器验证）

您可以在此处从有关OAuth的详细信息中获取更多信息。

图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 2.0的工作方式，本文对此进行了详细说明

这是一颗宝石：

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

非常简短的摘要：

OAuth定义了四个角色：

1. 资源所有者
2. 客户
3. 资源服务器
4. 授权服务器

您（资源所有者）拥有一部手机。您有多个不同的电子邮件帐户，但是您希望所有电子邮件帐户都在一个应用程序中，因此您无需继续切换。因此，您的GMail（客户端）要求（通过Yahoo的授权服务器）访问Yahoo电子邮件（资源服务器），以便您可以在GMail应用程序中阅读这两封电子邮件。

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

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

为了详细说明，特别是要解决OP的问题“ OAuth 2如何使用安全性令牌来防止诸如重放攻击之类的事情？”，在官方建议中还提供了另外两种保护措施，以实现 OAuth 2：

1）令牌通常具有较短的有效期（http://tools.ietf.org/html/rfc6819#section-5.1.5.3）：

令牌的有效时间短是一种防范以下威胁的方法：

• 重播...

2）当站点A使用令牌时，建议不要将其作为URL参数显示，而是在授权请求标头字段（http://tools.ietf.org/html/rfc6750）中显示：

客户端应该使用带有“ Bearer” HTTP授权方案的“ Authorization”请求标头字段，通过承载令牌发出经过身份验证的请求。...

除非在参与的浏览器无法访问“授权”请求标头字段的应用程序上下文中，否则不应使用“ application / x-www-form-urlencoded”方法。...

包含URI查询参数...以记录当前使用情况；由于其安全性缺陷，不建议使用

这可能是OAuth2如何适用于所有4种授权类型（即应用可以获取访问令牌的4种不同流）的最简单解释。

相似

所有授权类型流程都包含两个部分：

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

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

区别

每种授予类型的流程“获取访问令牌”的第一部分有所不同。

但是，通常，“获取访问令牌”部分可以归纳为5个步骤：

1. 向OAuth提供者（例如Twitter等）预先注册您的应用（客户端），以获取客户端ID /秘密
2. 在页面上创建具有客户端ID和所需范围/权限的社交登录按钮，以便在单击的用户重定向到OAuth提供程序进行身份验证时
3. OAuth提供者请求用户向您的应用（客户端）授予权限
4. OAuth提供者发出代码
5. 应用程序（客户端）获取访问令牌

这是一个并排图，比较了基于5个步骤的每种授权类型流程的不同。

此图来自https://blog.oauth.io/introduction-oauth2-flow-diagrams/

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

客户凭证：如果您的应用仅服务于单个用户

资源所有者密码凭证：仅当用户必须将其凭据移交给应用程序时，才应将其用作最后手段，这意味着应用程序可以执行用户可以做的所有事情

授权码：获得用户授权的最佳方法

隐式：如果您的应用是移动应用还是单页应用

这里有更多关于此选择的说明：https : //blog.oauth.io/choose-oauth2-flow-grant-types-for-app/