在较高的层面上，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

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

当我在上班途中看到最美味的甜甜圈时，我正在奥拉夫的面包店开车去工作 - 我的意思是，那东西正在滴下巧克力的美味。所以我进去了，并要求“我必须有那个甜甜圈！”。他说“肯定会是30美元。”

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

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

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

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

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

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

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

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

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

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

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

好的，我宁愿把口袋里的30美元递给他。但是现在他有那个说明我可以告诉银行让他每周花30美元，然后我就可以出现在面包店而且我不必再去银行了。如果我愿意，我甚至可以通过电话订购甜甜圈。

当然我永远不会这样做 - 甜甜圈很恶心。

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

Answer 2

根据我所读到的内容，这就是它的运作方式：

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

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

OAuth 2无法保护安全令牌或机密的重放攻击。相反，它完全依赖于站点B对这些项目负责而不让他们离开，并且在传输过程中通过https发送它们（https将保护URL参数）。

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

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资源服务器验证）

您可以从OAuth here的详细信息中获得更多信息。

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的工作原理，在this article

中有详细解释

Answer 6

这是一个宝石：

https://www.digitalocean.com/community/tutorials/an-introduction-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使用令牌时，建议不会将其显示为网址参数，而是显示在授权请求标头字段（http://tools.ietf.org/html/rfc6750）中：

  

客户端应该使用承载令牌进行经过身份验证的请求   具有“承载”HTTP的“授权”请求头字段   授权方案。   ...

     

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

     

包含URI查询参数...以记录当前使用情况;它的用途不是   建议，由于其安全性不足

Answer 8

关于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/