在较高的层面上,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美元.银行知道他是合适的人,因为他有他们给我给Olaf的那张便条.

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

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

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

Answer 2

基于我所读到的,这就是它的工作原理:

问题中概述的一般流程是正确的.在步骤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不起作用,因为可能有许多未完成的访问令牌等待同时发送到不同的站点.

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

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-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使用令牌时,建议不会将其显示为URL参数,而是显示在授权请求头字段(http://tools.ietf.org/html/rfc6750)中:

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

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

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

Answer 8

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

相似

所有资助类型流程都有 2 个部分：

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

第二部分“使用访问令牌”对于所有流都是相同的

不同之处

每种授权类型的流程“获取访问令牌”的第一部分各不相同。

然而，一般来说，“获取访问令牌”部分可以概括为 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/