OAuth2によるきめの細かい承認
OAuth2についての私の理解では、scopeを使用して、コード所有者が要求および付与するものへのアクセスを指定できます。
ほとんどの場合、スコープリストが閉じられ、アクセスできるものの「種類」を指定します。たとえば、profile、email、openidfrom Google Sign-in 。
スコープ内の特定のリソースへのアクセスをエンコードすることは意味がありますか？ アカウントのように：{アカウント番号}：rw
これは、ユーザーがリソースサーバーによって管理されている複数の個別のリソースを持っていて、特定のリソースへのサードパーティアクセスを承認したいが、リソースの「種類」ではない場合に使用します。たとえば、架空のアプリケーションはデータフォルダーを管理し、ユーザーUはフォルダー "/ A"への読み取りアクセス権を付与しますが、アプリケーションBには他のフォルダーを付与しません。
そのような場合、承認サーバーとリソースサーバーの両方が、そのようなオープンエンドスコープを解析して、具体的に処理する必要があることを理解しています。
そのアプローチには他に問題がありますか？
OAuth2はそのような場合に最適なテクノロジーですか？そうでない場合、代わりに何を使用しますか？
OAuthスコープの目的は委任された同意のフレームワークを提供することでしたが、これは裁量的な承認の形式ですが、ポリシー主導の承認とは異なりますリソースサーバーは、委任とポリシー主導のアプローチの両方を実施する責任があります。ポリシー主導の承認をモデル化しようとして、ロールベースのアクセス制御に似た場合、スコープはクレームのようになり、成長します権限（action-resource）マトリックス（read-account、write-accountなど）を使用して指数関数的に実行します。リソースサーバーの開発者は、各スコープが適用する意味を知る必要があります。 ） "）これにより、複雑なif-then-elseロジックを確認できます。
リソースサーバーが持つすべてのコンテキスト（id_token属性、リソースメタデータ、クライアントフットプリント、スコープ）を使用して「can [subject] do [action]この[context/env]の[resource]で？」ポリシー決定サービスは、リスク、コンテキスト、および「2要素認証が利用されているときにリソース所有者がアカウント所有者と関係を持っている場合に外部クライアントがアカウントの詳細を読み取ることができる」などのポリシー主導のルールを含むドメインです。 sを探す
TL; DR;
これは設計上の欠陥です。スコープはリソースを表し、クライアント（アプリケーション）に関連して、このアプリケーションがリソースにアクセスできることを通知します。このレベルの粒度はお勧めできません。この場合、アプリケーション（ユーザーではない）の特権のリストを維持するのは非常に困難になります。これは、それを行う方法ではありません。
その定義のスコープは、特権ではなく、リソースを識別する値です。スコープを承認サーバーに送信すると、スコープによって、ユーザーではなくクライアント（つまりアプリケーション）でアクセスしたいリソースを通知します。これは、アクセストークン（スコープ付き）を提示しているユーザーがアクセスするのが正当であるかどうかを解釈するリソースです。
OAuth2のスコープについて質問しましたが、OAuth2はAUTHORIZATIONの単なるフレームワークであり、認証用に定義されているわけではないことに注意してください。ユーザーの認証には、たとえばOAuth2に基づいて構築されたOpenIDConnect（OIDC）を使用する必要があります。
OIDCは、ユーザーデータのキャリアであるIDトークンを提示します。認可サーバーからIDトークンとアクセストークンを取得した場合、リソースは、特定のユーザーが必要なデータにアクセスできるかどうかを決定します。