「リソース所有者」という用語は、OAuth v2.0仕様で、「保護されたリソースへのアクセスを許可できるエンティティ。リソース所有者が個人である場合、エンドユーザーと呼ばれます」と定義されています。
私の質問は、リソースの所有者がエンドユーザーではないのはいつかということです。実際のユースケースとなる可能性のある例を通して説明していただければ幸いです。たとえば、保護されたリソースがFacebookユーザーの写真である場合、リソースの所有者はFacebookですか、それとも写真をアップロードしたFacebookユーザーですか。また、リソース所有者（つまり個人）がOAuthを実装しているアプリケーションのユーザーでさえない場合、そのユーザーがエンドユーザーと見なされるのはなぜですか？また、Facebookユーザーがリソース所有者である場合、この交換でFacebookはどのような役割を果たしますか？
リソースの所有者は、人だけでなく、マシンになることもできます。特にエンタープライズ設定では、OAuthフロー全体に人間が関与していない場合が多くあります。少なくとも、RFC 5849（および後でOAuth 2.0）でこの用語を導入したときに意味したことです。
リソースの所有者が企業である状況を考えてみてください。おそらく、リソースへのアクセスを有効/無効にするポリシーを持つ企業です。
アートの例を考えてみましょう。芸術作品で住居の見栄えを良くしたいとします。あなたが行くことができるいくつかの場所があります（例えば、コストコ）あなたは芸術作品を選ぶことができ、それをあなたの選んだ媒体にあなたの選んだサイズで印刷してあなたの家に届けることができます。
つまりね; コストコはその芸術作品のライセンス権の所有者ではありません。それは彼らのビジネスの領域の外です。彼らは物を売って、芸術を集めません。彼らがしていることは、コンテンツの所有者（アートのライセンスの所有者）と、そのアートを印刷物で使用する権利について交渉し、それを作成してあなたに提供することです。アートワークの費用はコストコに支払います。その後、コストコは、アートワークを使用する権利について、ライセンサーにあなたからの支払いの一部を支払います。
これは、リソース所有者とすでに関係がある状況でも機能します。たとえば、ある音楽の権利について交渉して購入したとします。あなたには音楽の所有者ではありません。音楽を転売する権利がないからです。しかし、あなたにはそれを聞く権利があります（これは標準的なDRMの状況です）。ここで、Webサイトを通じてその音楽を再生したいとします。あなたはその音楽のウェブサイトにリクエストをすることができます。ウェブサイトはあなたの身分証明書を使ってコンテンツ所有者（ライセンサー、実際には、しかし事実上同じです）に連絡することができます。その後、コンテンツ所有者は、ユーザーの条件に基づいて、コンテンツへのユーザー側のWebサイトアクセスを許可するかどうかを決定できます。
それがいくつかのことをクリアすることを願っています。
Facebook アプリを持っているとします。
ここで、すべてのユーザーのアクティビティに関する統計情報 (つまり、 「インサイト」 )を取得したいと考えています。
この場合、リソース ( "App Insights" ) は、各ユーザーではなくアプリによって所有されます。
したがって、アプリはクライアント アクセス トークン(2-legged OAuth と呼ばれる) を取得し、その分析情報にアクセスします。
Facebookは、ページのファン活動であるリソースとして「ページ インサイト」も提供しています。この場合、リソースはページのファンではなくページによって所有されているため、アプリはページのアクセス トークンを取得します。
しかし、私はあなたの混乱を理解することができます.
以前は、Facebook は、ページ所有者のアクセス トークンまたはページのアクセス トークンのいずれかを使用してページ インサイトへのアクセスを許可していました (これは、Facebook がページとページ所有者の両方のリソースとしてそれを処理したことを意味します。現在は、ページのアクセス トークンのみが許可されています)。
最後に、すべての場合において、Facebook は「認証サーバー」および「リソース サーバー」として機能します。ユーザーを認証し、リソースへのクライアント アクセスの承認を取得します。(認証サーバー)。リソースも提供します。(リソースサーバー)
私の会社は、画面共有ビデオ会議プロバイダーと協力しています。当社のユーザーは、自社のソリューションを当社の製品の一部として使用できます。当社とサードパーティ ツール間の通信は、2-legged OAuth を使用して API を呼び出すことで行われます。
私たちは人間ではありません。より適切な表現はおそらく外部システムですが、使用するリソースに対して支払いを行い、API の呼び出しを承認するエンティティであるため、間違いなくリソースの所有者です。
さらに、あなたが言及したFacebookの例では。リソース所有者は、写真をアップロードした人です。その人もエンドユーザーです。サード パーティ アプリケーションが API 呼び出しを発行するのは誰のためのものですか。
OAuth 2.0 に関連するより具体的な例を挙げて、@Paul Sonier の確かな反応を強調したいと思います。
企業環境では、企業の従業員は、企業の企業アカウントの保護下で、ファイル ストレージ サービス (Google ドライブ、Box.com、DropBox など) のコンテンツにアクセスしたい場合があります。
このようなサービスには、サービス プロバイダーのユーザー アカウントが動的にプロビジョニングされるか、一括でプロビジョニングされるシングル サインオンの取り決めが既にある場合があります。
重要なことに、従業員は通常、自分が作成するドキュメントやその他の作業に対するすべての権利を会社に譲渡します。法的な意味では、エンド ユーザーではなく会社がリソースの所有者です。
このような状況では、OAuth2 認証手順は不要です。会社は、サービス プロバイダーとの契約で、「IDP から認証されたすべてのユーザー セッションを、すべてのアプリケーションに対して事前に承認されていると見なす」と合理的に言うかもしれません。サービス プロバイダーは、これらのアプリの認証手順をスキップするだけで済みます。ところで、何千人もの従業員が混乱する手順やサポート デスクへの多くの電話などを省くことができます。
結局のところ、承認はデータ ストア内のエントリのみを許可し、OAuth 2.0 仕様外のポリシーに従うだけです。OAuth 2.0 仕様には、このような「一括認証」を防止または阻止するものは何もありません。これは、サービス プロバイダーと真のリソース所有者との間の合意の問題です。
このアプリケーション レベルの承認は、通常は帯域外で管理されるファイルおよびディレクトリのアクセス許可とは異なることに注意してください。つまり、ストレージ サービスは、ファイルとディレクトリへのユーザーおよびグループ レベルのアクセスを管理するための UI を提供します。次に、OAuth 2.0 クライアントは、ユーザー レベルのトークンを取得します (ほとんどのクライアントは、消費者向けの「承認コード」許可タイプのみをサポートします)。
仕様から：
リソース所有者- 保護されたリソースへのアクセスを許可できるエンティティ。リソース所有者が個人の場合、エンドユーザーと呼ばれます
この定義から、多くのエンティティが保護されたリソースへのアクセスを許可できる可能性があることがわかりました。
お気づきのように、人間の例は簡単に理解できます。保護された写真へのアクセスを要求すると、アクセスを許可できるエンティティは 1 つだけです。その実体は私です。あなたのリクエストを許可するには、何らかのアクションを実行する必要があります。アプリケーションによっては、ボタンをクリックしたり、テキスト メッセージを送信したり、話したり、拍手したり、何でもかまいません。アクションがキャプチャおよび処理されるメカニズムは、この定義には関係ありません。
この例を続けて、別のエンティティが私の保護された写真へのアクセスを許可できるとしましょう。あなたが写真ホスティング サービスの信頼できるビジネス パートナーであるとします。または、写真ホスティング会社の別のチームで、サーバーが同じデータセンター内で動作している場合もあります。このシナリオでは、保護された写真へのアクセス許可を自動的に付与することが望ましい場合があります。リソース サーバーが (あなたが誰であるかという理由で) アクセスを自動的に許可することを決定した場合、これは 2 番目のエンティティを表します。ここで、この人間以外のエンティティは、アクセス要求が自動的に受け入れられるべきであると (すべての知恵で) 決定しました。