术语“资源所有者”在OAuth v2.0 规范中定义为“能够授予对受保护资源的访问权限的实体。当资源所有者是个人时，它被称为最终用户。”
我的问题是，资源所有者何时不是最终用户？我希望通过可能是真实用例的示例进行解释。例如，如果受保护的资源是 Facebook 用户的照片，那么资源所有者是Facebook 还是上传照片的 Facebook 用户？此外，如果资源所有者（也是一个人）甚至不是实现 OAuth 的应用程序的用户，为什么该人会被视为最终用户？而且，如果 Facebook 用户是资源所有者，那么 Facebook 在这次交换中扮演什么角色？
资源所有者可以是一台机器，而不仅仅是人。在很多情况下，整个 OAuth 流程都没有人参与，尤其是在企业设置中。至少，这就是我在 RFC 5849（以及后来的 OAuth 2.0）中引入该术语时的意思。
考虑资源所有者是一家公司的情况，可能是一个具有启用/禁用对资源访问的策略的公司。
考虑一个艺术的例子；假设你想用一件艺术品让你的住所看起来更好；您可以去几个地方（例如 Costco），在那里您可以选择一件艺术品，以您选择的尺寸将其打印在您选择的介质上，然后送到您的家中。
事情是这样的；Costco 不是该艺术品许可权的所有者；这超出了他们的业务范围。他们卖东西，他们不收藏艺术品。他们所做的是与内容所有者（艺术许可的所有者）协商在印刷品中使用该艺术的权利，然后他们创建并交付给您。您为艺术品支付 Costco 费用；然后，Costco 会向许可人支付您支付的部分款项，以获得使用艺术品的权利。
这在您已经与资源所有者建立关系的情况下也适用；例如，假设您已经协商并购买了某些音乐的权利。您不是音乐的所有者，因为您无权转售音乐；但是您确实有权收听它（这是标准的 DRM 情况）。现在假设您想通过网站播放该音乐；您可以向网站请求该音乐；该网站可以使用您的身份联系内容所有者（实际上是许可方，但实际上是相同的）；然后，内容所有者可以根据您的条款决定是否授予您对内容的网站访问权限。
希望能解决一些问题。
假设您有一个 Facebook 应用程序。
现在您想要获取所有用户活动的统计信息（换句话说，“洞察力”）。
在这种情况下，资源（“App Insights”）归您的应用所有，而不是每个用户。
因此，您的应用会获得客户端访问令牌（称为 2-legged OAuth）并访问其洞察力。
Facebook 还提供“Page Insights”作为页面的粉丝活动资源。在这种情况下，资源属于页面而不是页面的粉丝，因此您的应用会获取页面的访问令牌。
不过我能理解你的困惑。
以前 Facebook 允许使用页面所有者的访问令牌或页面的访问令牌来访问页面洞察力。（这意味着 Facebook 将其作为页面和页面所有者的资源处理；现在只允许页面的访问令牌）
最后，在所有情况下，Facebook 都充当“授权服务器”和“资源服务器”。它对用户进行身份验证并获得客户端对其资源的访问权限的批准。（授权服务器）。它也提供资源。（资源服务器）
我的公司与屏幕共享视频会议提供商合作。我们的用户可以使用他们的解决方案作为我们产品的一部分。我们和第三方工具之间的通信是通过使用 2-legged OAuth 调用 API 进行的。
我们不是人，更好的措辞可能是外部系统，但我们绝对是资源所有者——因为我们为使用的资源付费，并且我们是授权调用 API 的实体。
此外，在您提到的 Facebook 示例中。资源所有者是上传照片的人。该人也是最终用户。让第三方应用程序受益的人会发出 API 调用。
我想用一个与 OAuth 2.0 相关的更具体的例子来强调@Paul Sonier 的可靠响应。
在企业环境中，公司的员工可能希望在公司的企业帐户的保护下访问文件存储服务（例如 Google Drive、Box.com、DropBox 等）上的内容。
此类服务可能已经具有单点登录安排，其中用户在服务提供商处的帐户是动态供应或批量供应的。
重要的是，员工通常会签署他们向公司提供的任何文件或其他工作的所有权利。在法律意义上，公司而不是最终用户是资源所有者。
在这种情况下，OAuth2 授权步骤是多余的。该公司在与服务提供商的合同中可能会合理地说，“将我们的 IDP 认证的任何用户会话视为对我们所有应用程序的预授权”。服务提供商可以简单地跳过这些应用程序的授权步骤，顺便说一句，为成千上万的员工节省了一个令人困惑的步骤和大量呼叫支持台的电话等。
归根结底，授权只授予数据存储中的一个条目，并受制于 OAuth 2.0 规范之外的策略。OAuth 2.0 规范中没有任何内容阻止或阻止此类“批量授权”。这只是服务提供者和真正的资源所有者之间的协议问题。
请注意，此应用程序级别授权与文件和目录权限不同，后者通常也是带外管理的。即存储服务提供用于管理用户和组级别对文件和目录的访问的 UI。然后，OAuth 2.0 客户端获取用户级令牌（大多数仅支持面向消费者的“授权码”授权类型）。
从规范：
资源所有者- 能够授予对受保护资源的访问权限的实体。当资源所有者是一个人时，它被称为最终用户
从这个定义中，我了解到许多实体可能能够授予对受保护资源的访问权限。
正如您所指出的，人类示例很容易理解 - 当您请求访问我受保护的照片时，只有一个实体能够授予访问权限。那个实体就是我。我必须执行一些操作来批准您的请求。根据应用程序的不同，这可能涉及单击按钮、发送文本消息、说话、鼓掌等等。捕获和处理我的操作的机制与此定义无关。
继续这个例子，假设另一个实体可以授予对我受保护照片的访问权限。想象一下，您是照片托管服务的值得信赖的业务合作伙伴。或者您可能是照片托管公司的另一个团队，并且您的服务器在同一个数据中心内运行。在这种情况下，可能需要自动授予您对受保护照片的权限。如果资源服务器决定自动授予您访问权限（因为您是谁），这将代表第二个实体。在这里，这个非人类实体已经决定（尽其所能）您的访问请求应该被自动接受。
资源所有者通常是用于从受保护的资源服务器检索记录的外键。
如果用户在资源服务器中拥有照片，则可以使用user_id从资源服务器中检索照片。
身份验证服务器在身份验证过程中检索用户ID（用户名/密码/OTP）。
防篡改（签名）JWT 令牌确保使用相同的user_id从资源服务器检索记录。
授权服务器使用外键生成 JWT 令牌（访问/ID）：user_id
Resource Server 接收 JWT 令牌以授权检索 Resource Owner (user_id) 拥有的记录 (Resources)。
SELECT * FROM 照片 WHERE user_id = '[jwt.payload. 用户ID ]';
现在，用任何（非最终用户）外键 替换user_id ，例如transaction_id
SELECT * FROM files WHERE transaction = '[jwt.payload. 交易ID ]'；
要确定资源所有者，请问自己：