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