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

Question

据我了解，以下事件发生在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如何防止使用安全令牌诸如重播攻击之类的事情？

Answer 1

根据我阅读的内容，这一切都是如何工作的：

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

总体而言，OAuth 2实际上是一个非常简单的安全模型，并且加密永远不会直接发挥作用。取而代之的是，秘密和安全令牌本质上都是密码，整个内容仅由HTTPS连接的安全性确保。

Oauth 2没有保护安全令牌或秘密的重播攻击。取而代之的是，它完全依赖于网站B负责这些项目，而不是让它们脱离，并且在运输过程中通过HTTPS发送（HTTPS将保护URL参数）。

授权代码步骤的目的只是便利性，并且授权代码本身并不特别敏感。它为用户X向用户X的访问令牌询问网站a的访问令牌提供了通用标识符。只需在网站B上的用户X的用户ID就无法正常工作，因为可能会有许多出色的访问令牌等待同时分发到不同的站点。

Answer 2

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

当我在窗户上看到最美味的甜甜圈时，我在上班的途中开车开车 - 我的意思是，这件事是在滴巧克力般的好处。所以我进去要求“我必须有那个甜甜圈！”。他说：“确定这将是30美元。”

是的，我知道，一个甜甜圈30美元！它一定很美味！当我突然听到厨师大喊：“不！没有甜甜圈为你”时，我伸手去拿钱包。我问：为什么？他说他只接受银行转让。

严重地？是的，他很认真。我差点走到那里，但是甜甜圈向我喊道：“吃我，我很美味……”。我是谁来不服从甜甜圈的命令？我说了可以。

他递给我一个带有他名字的笔记（厨师，而不是甜甜圈）：“告诉他们奥拉夫送你送你”。他的名字已经在笔记上，所以我不知道那是什么意义，但是还可以。

我开车一个半小时到达了我的银行。我把笔记交给了柜员。我告诉她奥拉夫寄给我。她给了我其中一种外观，说“我可以读”。

她记下我的笔记，问我的身份证，问我可以给他多少钱。我告诉她30美元。她做了一些涂鸦，给了我另一个笔记。这是一个数字，我猜这就是他们跟踪笔记的方式。

那时我饿了。一个半小时后，我冲出了那里，我回来了，站在奥拉夫的前面，张开了音调。他拿走了，看了看，说：“我会回来”。

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

嗯...所以奥拉夫记下来说银行给了我，然后回到银行里从我的帐户中赚钱。由于他给我留下了笔记，银行就知道他是我在谈论的那个人，而且因为我与银行交谈，他们知道只给他30美元。

我一定花了很长时间才能弄清楚这一点，因为到我抬头时，奥拉夫站在我面前 最后 递给我我的甜甜圈。在我离开之前，我不得不问：“奥拉夫，你总是以这种方式出售甜甜圈吗？”。 “不，我曾经做过不同。”

嗯。当我回到车上时，我的手机响了。我没有打扰回答，这可能是我呼唤我的工作，我的老板真是个***。此外，我被赶上了我刚刚经历的过程。

我的意思是考虑一下：我能够让奥拉夫从我的银行帐户中拿出30美元，而不必给他我的帐户信息。而且我不必担心他会拿出太多钱，因为我已经告诉银行只允许他花30美元。银行知道他是合适的人，因为他有他们给我给奥拉夫的便条。

好的，确保我宁愿从口袋里递给他30美元。但是现在他有了那张笔记，我可以告诉银行每周要花30美元，然后我可以出现在面包店，而我不必再去银行了。如果我愿意，我什至可以通过电话订购甜甜圈。

当然，我永远不会做到这一点 - 甜甜圈令人恶心。

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

Answer 3

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 Resource Server验证）

您可以从有关Oauth的详细信息中获得更多 这里.

Answer 4

图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 ---|               |
     +--------+                               +---------------+

Answer 5

这就是Oauth 2.0的工作方式，很好地解释了 本文

Answer 6

这是一颗宝石：

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

非常简短的摘要：

Oauth定义了四个角色：

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

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

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

Answer 7

另一个答案非常详细，并解决了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):

客户应使用“授权”标头字段使用“持有人” HTTP授权方案使用“授权”请求标题字段，并使用持票人令牌进行身份验证的请求。 ...

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

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

Answer 8

这也许是OAuth2如何适用于所有4种赠款类型的最简单的解释，即，该应用程序可以获取访问令牌的4种不同的流量。

相似

所有赠款类型流都有2个部分：

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

第二部分 “使用访问令牌” 所有流量都一样

区别

流的第一部分 “获取访问令牌” 对于每种赠款类型，各种各样的不同。

但是，总的来说 “获取访问令牌” 部分可以总结为组成5个步骤：

1. 使用OAuth提供商，例如，Twitter等预注册您的应用程序（客户端）。获取客户端ID/秘密
2. 在页面上创建一个具有客户ID和必需范围/权限的社交登录按钮
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/