首页 文章

在较高的层面上，OAuth 2如何运作？

提问于
浏览 次
531

据我了解，OAuth 2中发生以下事件链，以便 Site-A 从 Site-B 访问 User's 信息 .

  • Site-A 在 Site-B 上注册，并获取机密和ID .

  • 当 User 告诉 Site-A 访问 Site-B 时， User 被发送到 Site-B ，他告诉 Site-B 他确实想要给予特定信息 Site-A 权限 .

  • Site-B 将 User 重定向回 Site-A ，以及授权码 .

  • Site-A 然后将该授权码及其秘密传递回 Site-B 以换取安全令牌 .

  • Site-A 然后通过捆绑安全令牌和请求，代表 User 向 Site-B 发出请求 .

所有这些在高级别上如何在安全性和加密方面起作用？ OAuth 2如何使用安全令牌防止重放攻击等事情？

oauth-2.0

8 回答

  • 6

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

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

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

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

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

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

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

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

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

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

    我花了很长时间才弄明白这一点，因为当我抬起头来的时候，奥拉夫站在我面前，最后递给我甜甜圈 . 在我离开之前，我不得不问，"Olaf, did you always sell donuts this way?" . "No, I used to do it different."

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

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

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

    当然我永远不会那样做 - 甜甜圈很恶心 .

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

    回复于
  • 126

    基于我所读到的，这就是它的工作原理：

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

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

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

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

    回复于
  • 90

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

    这是一个用例演示：

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

    Add Connection

    • 当我输入我的帐户和密码时，会弹出一个网页，并显示Gmail登录页面：

    Add Connection

    • 然后Gmail会显示一个同意页面，我点击"Accept"：
      Add Connection

    • 现在，LinkedIn可以访问Gmail中的联系人：
      Add Connection

    以下是上述示例的流程图：

    Add Connection

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

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

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

    第4步：Gmail授权服务器使用访问令牌回复 .

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

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

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

    回复于
  • 11

    图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 ---|               |
     +--------+                               +---------------+
    回复于
  • 0

    这就是Oauth 2.0的工作方式，在this article中有详细解释

    enter image description here

    回复于
  • 9

    这是一个宝石：

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

    Very brief summary:

    OAuth定义了四个角色：

    • 资源所有者

    • 客户

    • 资源服务器

    • 授权服务器

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

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

    enter image description here

    回复于
  • 21

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

    为了详细阐述，特别是解决OP的"How does OAuth 2 protect against things like replay attacks using the Security Token?"问题，在实施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查询参数...以记录当前使用情况;不推荐使用它，由于其安全性不足

    回复于
  • 1314

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

    Similarity

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

    • 获取访问令牌

    • 使用访问令牌

    第二部分'use access token'对于所有流都是相同的

    Difference

    每种授权类型的流'get access token'的第1部分会有所不同 .

    但是，通常'get access token'部分可归纳为包含5个步骤：

    • 使用OAuth提供商（例如Twitter等）预注册您的应用（客户端）以获取客户端ID /机密

    • 在您的页面上创建一个具有客户端ID和所需范围/权限的社交登录按钮，以便在点击的用户被重定向到OAuth提供程序以进行身份验证时

    • OAuth提供商请求用户授予您的应用（客户端）权限

    • OAuth提供程序发出代码

    • App（客户端）获取访问令牌

    下面是一个并排的图表，根据5个步骤比较每个授权类型流程的不同之处 .

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

    enter image description here

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

    Client Credential ：如果您的应用仅为单个用户提供服务

    Resource Owner Password Crendential ：这应该仅作为最后的手段使用，因为用户必须将他的凭据移交给应用程序，这意味着应用程序可以执行用户可以执行的所有操作

    Authorization Code ：获得用户授权的最佳方式

    Implicit ：如果您的应用是移动应用或单页应用

    这里有更多的选择解释：https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/

    回复于

相关问题