📌  相关文章
📜  OAuth 2.0 的工作流程

📅  最后修改于: 2022-05-13 01:57:09.836000             🧑  作者: Mango

OAuth 2.0 的工作流程

OAuth2.0 是一种开放的行业标准授权协议，一旦用户授予访问其凭据的权限，第三方就可以代表用户获得对其他 HTTP 服务（例如 Google、Facebook 和 GitHub）的有限访问权限。

大多数网站都要求您先完成注册过程，然后才能访问其内容。您可能遇到过一些用于登录Google、Facebook或其他服务的按钮。

GeeksforGeeks 注册页面

单击这些按钮将使您无需输入任何凭据即可访问这些第三方服务。我相信你想知道这是怎么发生的。 OAuth揭示了这一点。

在深入了解 OAuth 之前，让我们快速回顾一下身份验证和授权。授权是指管理员向经过身份验证的用户授予访问权限的过程，而身份验证验证用户是他们声称的身份。

以GeeksforGeeks网站为例。

作为读者，您无需身份验证即可阅读博客，但要添加评论，您必须注册。注册后，您可以访问免费课程、改进文章并做出贡献。作为投稿人，您有权编辑您的文章。

现在让我们讨论 OAuth。

OAuth 是一个开放标准的授权框架，使第三方应用程序能够获得对用户数据的有限访问权限。

本质上， OAuth 是关于委托访问。

委托是所有者授权服务提供商代表所有者执行某些任务的过程。这里的任务是为另一方提供有限的访问权限。

让我们举两个现实生活中的例子；

房主经常联系房地产经纪人出售他们的房子。房主通过给他/她钥匙来授权房地产经纪人。经业主同意，代理人向买家展示该物业。欢迎买家查看房产，但不允许他们占用。在这种情况下，买方的访问权限受到限制，而访问权限受到代表业主行事的房地产经纪人的限制。

代客泊车的一个经典例子经常被重述以理解这个概念。在这种情况下，车主可以使用汽车和代客泊车。为了让他的车停好，车主将代客钥匙交给服务员。代客钥匙启动汽车并打开驾驶员侧车门，但阻止代客接近行李箱或手套箱中的贵重物品。

因此，代客钥匙已委派了限制代客访问的任务。

OAuth 的意义何在？

OAuth 允许细粒度的访问级别。与其将我们的全部受保护数据委托给第三方，我们更愿意只与他们共享必要的数据。因此，我们需要一个受信任的中介，一旦用户授予权限（称为同意），它将授予编辑器有限的访问权限（称为范围），而不会泄露用户的凭据。

这是用于编辑照片的应用程序的示例。

你去一个照片编辑应用程序来调整图像的大小。他们要求您从 Google Drive 帐户上传要编辑的图像。第三方只需要访问您需要编辑的单张照片。 Oauth 将确保照片编辑器能够做到这一点。

再举一个例子，你想把你编辑的照片分享给你的朋友，但他们必须有相同的编辑软件。编辑软件无法请求您的 Google 帐户凭据；相反，它会将您重定向到您的帐户。如果您选择通过该应用邀请您的朋友，该应用将请求访问您的 Google 通讯录以发送邀请。

  • 只读/只写-第三方只能读取您的数据，不能修改它。在某些情况下，它还可以请求对您的帐户进行内容修改。例如，您可以将 Instagram 帐户中的图片交叉发布到 Facebook 帐户。
  • 撤销访问权限 –您可以取消 Instagram 对您 Facebook 墙的访问权限，使其无法再在您的墙上发布。

在了解 OAuth 的工作原理之前，我们将讨论OAuth 的核心组件以更清楚地说明。

下面列出了 OAuth 的元素：

  1. 演员
  2. 范围和同意
  3. 代币
  4. 流动

演员：

OAuth 交互具有以下 Actor：

OAuth2.0 参与者

  • 资源是需要 OAuth 才能访问的受保护数据。
  • 资源所有者：拥有资源服务器中的数据。能够授予对受保护数据的访问权限的实体。例如，用户 Google Drive 帐户。
  • 资源服务器：存储数据的 API。例如，Google 相册或 Google 云端硬盘。
  • 客户端：它是想要访问您的数据的第三方应用程序，例如照片编辑器应用程序。

访问资源的两个服务之间似乎存在交互，但问题是谁负责安全。资源服务器（在本例中为 Google Drive）负责确保所需的身份验证。

OAuth 与资源服务器耦合。 Google 实施 OAuth 来验证访问资源的人的授权。

  • 授权服务器：创建访问令牌的 OAuth 的主要引擎。

范围和同意：

范围定义了应用程序可以代表用户执行的特定操作。它们是客户端在请求令牌时要求的权限包。

例如，我们可以通过 LinkedIn 本身在 Twitter 上分享我们的 LinkedIn 帖子。鉴于它具有只写访问权限，它无法访问其他信息，例如我们的对话。

在同意屏幕上，用户了解谁在尝试访问他们的数据以及他们想要访问什么样的数据，并且用户必须表示同意允许第三方访问所请求的数据。当您将 GitHub 帐户链接到它或导入现有存储库时，您授予对 IDE 的访问权限，例如 CodingSandbox。您正在使用的 Github 帐户将向您发送一封确认此消息的电子邮件。

GitHub 确认电子邮件

现在让我们谈谈访问和刷新令牌。

什么是令牌？

令牌是一段数据，其中包含足够的信息以能够验证用户的身份或授权他们执行特定操作。

我们可以通过电影院的类比来理解访问令牌和刷新令牌。假设你（资源拥有者）想看最新的漫威电影（商驰与十环传奇），你会去售票处（授权服务器），选择电影，然后购买票（令牌）那部电影（范围）。门票有效期现在仅适用于特定时间范围和特定节目。保安检查您的票后，他让您进入剧院（资源服务器）并引导您到指定的座位。

如果你把票给朋友，他们可以用它看电影。 OAuth 访问令牌的工作方式相同。任何拥有访问令牌的人都可以使用它来发出 API 请求。因此，它们被称为“不记名令牌”。您不会在机票上找到您的个人信息。类似地，可以创建 OAuth 访问令牌，而无需实际包含有关向其颁发令牌的用户的信息。与电影票一样，OAuth 访问令牌在一段时间内有效，然后过期。安全人员通常会要求提供身份证明来验证您的年龄，尤其是对于 A 级电影。在向您提供门票之前，在线预订将由应用程序进行身份验证。

因此，访问令牌是用于访问受保护资源的凭据。每个令牌代表资源所有者授予并由授权服务器强制执行的访问范围和持续时间。根据资源服务器的安全需求，使用访问令牌的格式、结构和方法可能会有所不同。

一个解码的访问令牌，遵循 JWT 格式。 

{ "iss": "https://YOUR_DOMAIN/",
 "sub": "auth0|123456",
  "aud": [   "my-api-identifier",   "https://YOUR_DOMAIN/userinfo" ],
  "azp": "YOUR_CLIENT_ID", "exp": 1474178924, "iat": 1474173924,
  "scope": "openid profile email address phone read:meetings" }   

现在您的放映时间已过，您想再看一部电影，您需要购买一张新票。在您最后一次购买时，您会收到一张有效期为三个月的礼品卡。您可以使用此卡购买新票。在这种情况下，礼品卡类似于 Refresh Tokens 。刷新令牌是授权服务器发给客户端的字符串，用于在当前访问令牌失效时获取新的访问令牌。

他们不刷新现有的访问令牌，他们只是请求一个新的。刷新令牌的过期时间往往比访问令牌长得多。在我们的例子中，礼品卡的有效期为三个月，而机票的有效期为两个小时。与原始访问令牌不同，它包含的信息较少。

现在让我们看看在将图片上传到照片编辑器以了解工作流程时 OAuth 的工作原理。

  1. 资源所有者或用户希望调整图像大小，因此他去找编辑器（客户端），告诉客户端图像在 Google Drive（资源所有者）中，并要求客户端将其拿来进行编辑。
  2. 客户端向授权服务器发送请求以访问图像。服务器要求用户授予相同的权限。
  3. 一旦用户允许第三方访问并使用谷歌登录网站，授权服务器就会向客户端发送一个短暂的授权码。
  4. 客户端交换访问令牌的身份验证代码，它定义了用户访问的范围和持续时间。
  5. 授权服务器验证访问令牌，编辑器从他们的 Google Drive 帐户中获取用户想要编辑的图像。

OAuth 工作流程概述

1.授权码流程：

授权码流程

  1. 客户端通过将资源所有者定向到授权服务器来请求授权。
  2. 授权服务器对资源所有者进行身份验证，并将客户端和客户端请求的数据通知用户。客户端无法访问用户凭据，因为身份验证是由身份验证服务器执行的。
  3. 一旦用户授予访问受保护数据的权限，授权服务器就会使用临时授权码将用户重定向到客户端。
  4. 客户端请求访问令牌以换取授权码。
  5. 授权服务器对客户端进行身份验证，验证代码，并向客户端颁发访问令牌。
  6. 现在客户端可以通过向资源服务器提供访问令牌来访问受保护的资源。
  7. 如果访问令牌有效，则资源服务器将请求的资源返回给客户端。

2. 隐式流：

隐式授权流程是基于浏览器的应用程序的授权流程。隐式授权类型是为单页 JavaScript 应用程序设计的，用于在没有中间代码交换步骤的情况下获取访问令牌。单页应用程序是那些页面不重新加载并且动态加载所需内容的应用程序。以 Facebook 或 Instagram 为例。 Instagram 不需要您重新加载应用程序即可查看帖子上的评论。无需重新加载页面即可进行更新。因此，隐式授权流适用于此类应用。

隐式流程直接向客户端发出访问令牌，而不是发出授权码。

隐式赠款：

  • 构造一个链接并将用户浏览器重定向到该 URL。
https://example-app.com/redirect  #access_token=g0ZGZmPj4nOWIlTTk3Pw1Tk4ZTKyZGI3  &token_type=Bearer  &expires_in=400  &state=xcoVv98y3kd55vuzwwe3kcq   
  • 如果用户接受请求，授权服务器会将浏览器返回到客户端应用程序提供的重定向 URL，并在 URL 的片段部分附加令牌和状态。 （状态是字符串唯一且不可预测的字符。）
  • 为防止跨站点伪造攻击，一旦启动重定向，应用程序应根据最初设置的值测试传入状态值。 （如果我们收到状态不匹配的响应，我们就是攻击的目标）。
  • 重定向 URI 包括发送到客户端的访问令牌。客户端现在可以访问资源所有者授予的资源。

由于缺少客户端身份验证，此流程已被弃用。如果恶意应用程序获得客户端凭据，则它可以伪装成客户端，如果检查页面的源代码，这些凭据是可见的，这使所有者容易受到网络钓鱼攻击。

没有像中间授权代码这样的安全反向通道——所有通信都是通过隐式授权处理中的浏览器重定向进行的。为了降低访问令牌受到潜在攻击的风险，大多数服务器都会发布短期访问令牌。

3. 资源所有者密码凭证流程：

在此流程中，所有者的凭据（例如用户名和密码）被交换为访问令牌。用户直接向应用程序提供他们的凭据，然后应用程序利用这些凭据从服务获取访问令牌。

  1. 客户端应用程序要求用户提供凭据。
  2. 客户端向授权服务器发送请求以获取访问令牌。
  3. 授权服务器对客户端进行身份验证，确定它是否有权发出此请求，并验证用户的凭据。如果一切都验证成功，它会返回一个访问令牌。
  4. OAuth 客户端使用访问令牌对资源服务器进行 API 调用以访问受保护的数据。
  5. 资源服务器授予访问权限。

例如， Microsoft 标识平台支持资源所有者密码凭据流，这使应用程序能够直接使用用户的凭据登录用户。

它适用于与客户建立信任关系的资源所有者。对于非 API 提供者官方发布的第三方应用，不推荐使用。

为什么不建议使用资源所有者密码凭据授予类型？

  1. 冒充：有人可能冒充用户请求资源，因此无法验证所有者是否提出了请求。
  2. 网络钓鱼攻击——随机客户端应用程序要求用户提供凭据。而不是在应用程序请求您的 Google 用户名和密码时将您重定向到您的 Google 帐户。
  3. 用户的凭据可能会被恶意泄露给攻击者。
  4. 客户端应用程序可以从授权服务器请求它想要的任何范围。尽管受控范围，客户端应用程序可能能够在未经用户许可的情况下访问用户资源。

例如，在 2017 年，一个虚假的 Google Docs 应用程序被用来欺骗用户认为它是 Google 提供的合法产品。攻击者使用此应用程序通过滥用 OAuth 令牌访问用户的电子邮件帐户。

4. 客户凭证流程：

客户端凭据流允许客户端服务使用自己的凭据，而不是冒充用户访问受保护的数据。在这种情况下，授权范围仅限于客户端控制的受保护资源。

  1. 客户端应用程序使用其客户端凭据向授权服务器发出授权请求。
  2. 如果凭据准确无误，服务器将使用访问令牌进行响应。
  3. 该应用程序使用访问令牌向资源服务器发出请求。
  4. 资源服务器在响应请求之前验证令牌。

OAuth 2.0 与 Oauth 1. 0

OAuth 的版本不兼容，因为 OAuth 2.0 是对 OAuth 1.0 的彻底改造。实施 OAuth 2.0 更加简单快捷。 OAuth 1.0 具有复杂的加密要求，仅支持三个流，并且不可扩展。

既然您知道忘记 Facebook 密码时幕后会发生什么，它会通过您的 Google 帐户验证您并允许您更改它，或者任何其他应用程序将您重定向到您的 Google 帐户时，您将更好地了解这个怎么运作。