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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

这里可能是OAuth2如何为所有4种授权类型工作的最简单的解释，即应用程序可以获得访问令牌的4个不同的流。

相似

所有授权类型流都有两部分:

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

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

区别

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

然而，一般来说，“获取访问令牌”部分可以概括为5个步骤:

预先注册你的应用(客户端)与OAuth提供商，例如，Twitter等，以获得客户端id/秘密 在你的页面上创建一个带有客户端id和所需范围/权限的社交登录按钮，这样当点击用户时就会被重定向到OAuth提供者进行身份验证 OAuth提供商请求用户授予你的应用(客户端)权限 OAuth提供者发布代码 App(客户端)获取访问令牌

下面是一个并排的图表，比较了基于5个步骤的每个拨款类型流程的不同。

这个图表来自https://blog.oauth.io/introduction-oauth2-flow-diagrams/

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

客户端凭证:如果你的应用程序只服务于一个用户

资源所有者密码凭据:这应该仅作为最后的手段，因为用户必须将他的凭据移交给应用程序，这意味着应用程序可以做用户所能做的一切

授权代码:获得用户授权的最佳方式

隐式:如果你的应用是移动应用或单页应用

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

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

问题中概括的大致流程是正确的。在步骤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是行不通的，因为可能有许多未完成的访问令牌等待同时分发到不同的站点。

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

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

令牌通常有一个很短的有效期(https://www.rfc-editor.org/rfc/rfc6819#section-5.1.5.3):

令牌的短到期时间是一种保护手段 以下威胁: 重播…

站点A使用令牌时，建议它不作为URL参数，而是在授权请求报头字段(https://www.rfc-editor.org/rfc/rfc6750):)中显示

客户端应该使用承载令牌进行身份验证请求 “授权”请求头字段与“承载”HTTP 授权方案。 .．. 不应该使用"application/x-www-form-urlencoded"方法 除非在应用程序上下文中，其中参与的浏览器不这样做 可以访问“授权”请求头字段。 .．. URI查询参数…用于记录当前使用情况;它的用途不是 推荐，由于其安全性不足

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上找到更多信息