OAuth 2如何使用安全令牌防止重放攻击等事情？

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

1. Site-A在Site-B上注册，并获取Secret和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如何使用安全令牌防止重放攻击等事情？

---

#1楼

另外一个答案很是详细，解决了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受权方案的“受权”请求头字段，使用承载令牌进行通过身份验证的请求。 ...

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

包含URI查询参数...以记录当前使用状况; 因为其安全性不足，不建议使用它

---

#2楼

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的详细信息。

---

#3楼

OAuth 2.0如何在现实生活中发挥做用：

当我在窗口看到最美味的甜甜圈时，我正在去奥拉夫的面包店开车去工做 - 个人意思是，那东西正在滴下巧克力的美味。 因此我进去了，并要求“我必须有那个甜甜圈！”。 他说“确定会是30美圆。”

是的，我知道，一个甜甜圈30美圆！ 必定很好吃！ 当我忽然听到厨师大喊“不！没有甜甜圈给你”时，我伸手去拿钱包。 我问：为何？ 他说他只接受银行转帐。

真的吗？ 是的，他很认真。 我差点就走了，而后甜甜圈叫我：“吃我，我好吃......”。 我是谁不遵照甜甜圈的命令？ 我说了能够。

他递给我一张带有他名字的便条（厨师，而不是甜甜圈）：“告诉他们奥拉夫送你的”。 他的名字已经在笔记上了，因此我不知道那是什么意思，可是好的。

我开了一个半小时到个人银行。 我把票据递给了出纳员; 我告诉她奥拉夫送个人。 她给了我其中一个外表，那种说“我能看懂”。

她接过个人笔记，问个人身份，问我能够给他多少钱。 我告诉她30美圆。 她作了一些涂鸦并递给我另外一张纸条。 这个上面有一堆数字，我猜他们是如何跟踪笔记的。

那时我正在挨饿。 我赶忙离开那里，一个半小时后我回来了，站在奥拉夫面前，个人笔记延长了。 他接过它，看着它说：“我会回来的”。

我觉得他正在吃甜甜圈，但30分钟后我就开始怀疑了。 因此我问柜台后面的那我的“奥拉夫在哪里？”。 他说“他去赚钱”。 “你什么意思？”。 “他注意到银行”。

嗯......因此奥拉夫接过银行给个人说明，而后回到银行从个人账户中取钱。 因为他收到了银行给个人那张纸条，银行知道他就是那个我正在谈论的那我的，并且由于我跟银行说话，他们知道只给他30美圆。

我花了很长时间才弄明白这一点，由于当我抬起头来的时候，奥拉夫站在我面前， 最后递给我甜甜圈。 在我离开以前，我不得不问：“奥拉夫，你老是以这种方式卖甜甜圈吗？” “不，我曾经作过不一样的事情。”

呵呵。 当我走回个人车时，个人电话响了。 我没有打扰回答，这多是个人工做要求解雇我，个人老板是这样的***。 此外，我被卷入思考我刚刚经历的过程。

个人意思是考虑一下：我可以让Olaf从个人银行帐户中拿走30美圆而没必要向他提供个人帐户信息。 并且我没必要担忧他会花太多钱，由于我已经告诉银行他只能拿走30美圆。 银行知道他是合适的人，由于他有他们给我给Olaf的那张便条。

好吧，我宁愿把口袋里的30美圆递给他。 可是如今他有那个说明我能够告诉银行让他每周花30美圆，而后我就能够出如今面包店并且我没必要再去银行了。 若是我愿意，我甚至能够经过电话订购甜甜圈。

固然我永远不会那样作 - 甜甜圈很恶心。

我想知道这种方法是否有更普遍的应用。 他提到这是他的第二种方法，我能够称之为Olaf 2.0。 无论怎样，我最好回家，我得开始寻找新工做。 可是，在我从镇上的新地方获得其中一种草莓奶昔以前，我须要一些东西来洗去那个甜甜圈的味道。

---

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

---

#5楼

这就是Oauth 2.0的工做原理，在本文中有很好的解释