这是一块宝石:

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

非常简短的总结:

OAuth定义了四个角色:

资源所有者 客户端 资源服务器 授权服务器

您(资源所有者)有一部手机。你有几个不同的电子邮件帐户，但你希望所有的电子邮件帐户都在一个应用程序中，所以你不需要一直切换。因此，您的GMail(客户端)要求访问(通过雅虎的授权服务器)到您的雅虎电子邮件(资源服务器)，以便您可以在GMail应用程序上阅读这两封电子邮件。

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

这是一块宝石:

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

非常简短的总结:

OAuth定义了四个角色:

资源所有者 客户端 资源服务器 授权服务器

您(资源所有者)有一部手机。你有几个不同的电子邮件帐户，但你希望所有的电子邮件帐户都在一个应用程序中，所以你不需要一直切换。因此，您的GMail(客户端)要求访问(通过雅虎的授权服务器)到您的雅虎电子邮件(资源服务器)，以便您可以在GMail应用程序上阅读这两封电子邮件。

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

OAuth 2.0在现实生活中的工作原理:

我开车去上班的路上经过奥拉夫面包店，看到橱窗里最好吃的甜甜圈——我的意思是，那东西滴着巧克力般的美味。所以我走了进去，要求“我必须要那个甜甜圈!”他说:“当然是30美元。”

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

严重吗?是的，他是认真的。我差点就走开了，但这时甜甜圈对我喊道:“吃了我，我很好吃……”我凭什么违抗甜甜圈的命令?我说好的。

他递给我一张纸条，上面写着他的名字(是厨师，不是甜甜圈):“告诉他们奥拉夫让你来的。”他的名字已经写在纸条上了，所以我不知道这么说有什么意义，不过好吧。

我开了一个半小时的车去银行。我把钞票递给出纳员。我告诉她奥拉夫派我来的。她看了我一眼，好像在说:“我识字。”

她拿着我的纸条，问我要身份证，问我可以给他多少钱。我告诉她30美元。她草草写了几笔，又递给我一张纸条。这个上面有一堆数字，我猜这是他们记录音符的方法。

那时我饿坏了。我冲了出去，一个半小时后我回来了，站在奥拉夫面前，手里拿着我的纸条。他拿了过来，看了看，说:“我会回来的。”

我以为他在买我的甜甜圈，但30分钟后我开始怀疑了。所以我问柜台后面的人“奥拉夫在哪里?”他说"他去拿钱了"“你这是什么意思?”“他把票据送到银行去了。”

嗯……于是奥拉夫拿着银行给我的条子，回到银行去从我的账户里取钱。因为他有银行给我的票据，银行知道他就是我说的那个人，而且因为我和银行谈过，他们知道只给他30美元。

我一定花了很长时间才弄明白，因为当我抬起头来的时候，奥拉夫终于站在我面前，把我的甜甜圈递给了我。在我离开之前，我不得不问:“奥拉夫，你总是这样卖甜甜圈吗?”“不，我以前做的不一样。”

嗯。当我走回我的车时，我的电话响了。我没去接，可能是我的工作让我开除的，我的老板真是个***。此外，我一直在想我刚刚经历的过程。

我的意思是，想想看:我可以让奥拉夫从我的银行账户中取出30美元，而不必把我的账户信息告诉他。我也不用担心他会取太多的钱，因为我已经告诉银行他只能取30美元。银行知道他是合适的人因为他有他们让我交给奥拉夫的纸条。

好吧，我宁愿从口袋里掏出30美元给他。但现在他有了那张钞票，我可以告诉银行让他每周拿30美元，然后我就可以去面包店了，再也不用去银行了。如果我愿意，我甚至可以通过电话订购甜甜圈。

我当然不会那么做，那个甜甜圈太恶心了。

我想知道这种方法是否有更广泛的应用。他提到这是他的第二种方法，我可以称之为Olaf 2.0。总之我得回家了，我得开始找新工作了。但在我从镇另一头的新店里买到草莓奶昔之前，我需要一些东西来洗掉甜甜圈的味道。

OAuth是一种协议，第三方应用程序可以在不需要您的帐户和密码的情况下访问存储在另一个网站上的数据。有关更正式的定义，请参考Wiki或规范。

下面是一个用例演示:

我登录领英，想联系我Gmail联系人中的一些朋友。LinkedIn支持这一点。它将从gmail请求一个安全资源(我的gmail联系人列表)。我点击这个按钮: 弹出一个网页，它显示Gmail登录页面，当我输入我的帐户和密码: Gmail然后显示一个同意页面，我点击“接受”: 现在LinkedIn可以访问我在Gmail的联系人:

下面是上面例子的流程图:

步骤1:LinkedIn从Gmail的授权服务器请求一个令牌。

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

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

步骤4:Gmail授权服务器返回一个访问令牌。

步骤5:LinkedIn使用这个访问令牌调用Gmail API。

步骤6:如果访问令牌有效，Gmail资源服务器将返回您的联系人。(令牌将由Gmail资源服务器验证)

你可以在这里获得更多关于OAuth的细节。

OAuth2本身并不能保护您免受重放攻击。但是，可以使用MTLS或DPoP等“扩展”。你可以在https://marcinjahn.com/technologies/security/oauth2/sender-constraint.html上找到更多信息

根据我所读到的，它是这样运作的:

问题中概括的大致流程是正确的。在步骤2中，用户X经过身份验证，并授权站点A访问站点B上的用户X的信息。在步骤4中，站点将其Secret传递回站点B，验证自身以及授权码，表明它正在请求什么(用户X的访问令牌)。

总的来说，OAuth 2实际上是一个非常简单的安全模型，加密从未直接发挥作用。相反，Secret和Security Token本质上都是密码，整个事情仅由https连接的安全性保护。

OAuth 2没有针对安全令牌或秘密的重放攻击的保护。相反，它完全依赖于站点B负责这些项目，不让它们流出，并在传输过程中通过https发送(https将保护URL参数)。

授权码步骤的目的只是为了方便，而授权码本身并不是特别敏感。当向站点B请求用户X的访问令牌时，它为站点a的用户X的访问令牌提供了一个公共标识符。仅在站点B上使用用户X的用户id是行不通的，因为可能有许多未完成的访问令牌等待同时分发到不同的站点。