在高层次，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将用户redirect到Site-A以及授权码。
4. Site-A然后将该授权码连同其秘密一起传递回Site-B以换取安全令牌。
5. 然后Site-A通过捆绑安全令牌和请求，代表用户向Site-B发出请求。

所有这些在安全和encryption方面如何在高层次上工作？ OAuth 2如何防止使用安全令牌的重放攻击？

Answer 1

OAuth 2.0如何在现实生活中运作：

当我在窗口看到最美味的甜甜圈的时候，我正在去奥拉夫面包店的路上开车 – 我的意思是，那东西正在滴下巧克力的美味。 于是我走进去，问道：“我必须吃那个甜甜圈！” 他说“肯定会是30美元”。

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

真的吗？ 是的，他很认真。 我几乎走到那里，但是甜甜圈对我说：“吃我，我好吃…”。 我是谁不服从甜甜圈的命令？ 我说好。

他递给我一张纸条，上面写着他的名字（厨师，不是甜甜圈）：“告诉他们奥拉夫寄给你”。 他的名字已经在注释中，所以我不知道这是什么意思，但可以。

我开车一个半小时到我的银行。 我把纸条交给出纳员。 我告诉她奥拉夫送我了。 她给了我一个这样的样子，那种说：“我可以读”。

她拿了我的笔记，问我的身份证，问我可以给他多less钱。 我告诉她30美元。 她做了一些涂鸦，递给我另一张纸条。 这个人有一堆数字，我猜他们是如何跟踪笔记。

那时我正在挨饿。 我冲了出去，一个半小时后，我回来了，站在奥拉夫面前，我的笔记伸了出来。 他拿起它，看了看，说：“我会回来的”。

我以为他得到我的甜甜圈，但30分钟后，我开始怀疑。 于是我问柜台后面的那个人：“奥拉夫在哪里？”。 他说“他去拿钱”。 “你什么意思？”。 “他注意到银行”。

呵呵……所以奥拉夫接过logging，银行给了我，然后回到银行把钱从我的账户里拿出来。 既然他有银行给我的钞票，银行就知道他是我所说的那个人，而且因为我跟银行交谈，他们知道只给他30美元。

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

呵呵。 当我回到我的车时，我的手机响了。 我没有打扰回答，这可能是我的工作要求解雇我，我的老板是这样一个***。 此外，我还想起了刚刚经历的这个过程。

我的意思是考虑一下：我可以让Olaf从我的银行账户中拿出30美元，而不必把账户信息给他。 而且我也不必担心他会拿出太多钱，因为我已经告诉银行他只能拿到30美元。 银行知道他是正确的人，因为他有给我的钱给奥拉夫。

好吧，我确定我宁愿从他口袋里拿出30美元。 但现在他有了这张纸条，我可以告诉银行让他每周花30美元，然后我可以出现在面包店，我不必再去银行了。 如果我想，我甚至可以通过电话订购甜甜圈。

当然，我绝对不会这么做 – 那个甜甜圈真恶心。

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

Answer 2

根据我所读到的，这是如何工作的：

问题中概述的一般stream程是正确的。 在步骤2中，用户X被authentication，并且还授权站点A访问站点B上的用户X的信息。在步骤4中，站点将其秘密传递回站点B，自我authentication以及授权码，指示它要求（用户X的访问令牌）。

总的来说，OAuth 2实际上是一个非常简单的安全模型，encryption永远不会直接发挥作用。 相反，秘密和安全令牌本质上都是密码，整个事情只能通过https连接的安全来保护。

OAuth 2没有保护安全令牌或秘密的重放攻击。 相反，它完全依赖于站点B负责这些项目，不让他们出去，并在他们通过HTTPS传输（https将保护URL参数）。

授权代码步骤的目的仅仅是方便，授权代码本身并不特别敏感。 当向站点B询问用户X的访问令牌时，它为站点A的用户X的访问令牌提供公共标识符。 只要用户X在B站点上的用户标识就无法工作，因为可能有许多未完成的访问令牌同时等待分发到不同的站点。

Answer 3

OAuth是一个协议，三方应用程序可以在没有您的帐户和密码的情况下访问存储在另一个网站上的数据。 更为官方的定义，请参阅Wiki或规范。

这是一个用例演示：

1. 我loginLinkedIn并希望连接Gmail联系人中的一些朋友。 LinkedIn支持这个，所以我点击这个button：
   

2. 当我input我的帐户和密码时，一个网页popup，并显示Gmaillogin页面：
   

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

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

下面是上面的例子的stream程图：

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

步骤2：Gmail授权服务器validation资源所有者并向用户显示同意页面。 （如果用户尚未login，则需要loginGmail）

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

第4步：Gmail授权服务器回应一个访问令牌。

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

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

您可以从这里了解有关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

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

为了详细说明，特别是解决OP的问题：“OAuth 2如何防止使用安全令牌的重放攻击？”，在实现 OAuth 2的官方build议中还有两个额外的保护措施：

1）令牌通常有一个短的到期期限（ http://tools.ietf.org/html/rfc6819#section-5.1.5.3 ）：

令牌短期到期是防范下列威胁的一种手段：

• 重播…

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

客户端应该使用具有“承载”HTTP授权scheme的“授权”请求头字段，使用不记名令牌进行authentication请求。 …

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

包含URI查询参数…以logging当前的使用情况; 由于其安全缺陷，不build议使用它

Answer 6

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

Answer 7

这是一个gem：

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

非常简短的总结：

OAuth定义了四个angular色：

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

你（资源所有者）有一部手机。 你有几个不同的电子邮件帐户，但你想在一个应用程序的所有电子邮件帐户，所以你不需要保持转换。 所以你的Gmail（客户端）要求访问（通过雅虎的授权服务器）你的雅虎邮件（资源服务器），所以你可以阅读你的GMail应用程序的两封电子邮件。

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