リソースプロバイダーはOAuth2トークンをどのように検証する必要がありますか？
リソースプロバイダーは、多くの場合、リソースへの読み取りおよび書き込みアクセスを提供します。
したがって、リソースプロバイダーはトークンを検証するだけでなく（期限切れですか？取り消されていますか？有効ですか？必要なスコープが含まれていますか？）、トークンの特権も確認する必要があります（XYは読み取りまたは書き込みに十分な特権を持っていますか？）リソースZY？）。
これまでは、次のワークフローを使用しました。
- クライアントは、OAuth2コード付与を通じてアクセストークンを受け取ります。
- クライアントは、ユーザーに代わって、たとえば
GET /user_postings - リソースサービス（呼び出してみましょうser Postings）は、承認サーバーにリクエストを送信してトークンを検証し、トークンが有効であることを確認します。承認サーバーはさらに、トークンの有効期限、トークンの対象者、トークンのスコープ、トークンのサブジェクト（ユーザーXYなど）などのメタデータを渡します
- Resource Serviceは、サブジェクト（ユーザーXYなど）がリクエストの実行を許可または許可されていることを検証します。たとえば、アクセス制御リストなどをチェックします。例：ユーザーXYがユーザーABによる投稿を更新したいとします。これは、たとえば、アクセス制御リストによって禁止されます。
- 検証に合格すると、リソースサーバーは要求を実行します。
これは物事を行う有効な方法ですか、それとも攻撃ベクトルを開いていますか？リソースサーバーは、トークンのサブジェクトが承認要求と見なされるものであると想定しても問題ありませんか？これを解決するためのベストプラクティスまたは標準はありますか？
OAuth2は委任のみであり、承認でも認証でもないこと、そしてclientsは「トークンXYがユーザーABに属しているため、ユーザーABが認証される」などの暗黙の仮定を行うべきではないため、現在混乱しています。
どんな助けでも喜んで感謝されます。
RFC 675 、OAuth 2.0 Authorization Framework：Bearer Token Usage、 セクション5：セキュリティに関する考慮事項 ベアラートークンの使用に関連するいくつかの問題について説明します。セクション5.2から：
5.2。脅威の軽減
デジタル署名またはメッセージ認証コード（MAC）を使用してトークンの内容を保護することにより、広範囲の脅威を軽減できます。または、ベアラートークンには、認証情報を直接エンコードするのではなく、認証情報への参照を含めることができます。このような参照は、攻撃者が推測することは不可能でなければなりません。参照を使用すると、認証情報への参照を解決するために、サーバーとトークン発行者の間の追加の相互作用が必要になる場合があります。このような相互作用のメカニズムは、この仕様では定義されていません。
ワークフローのステップ3で、トークンが有効かどうかを承認サービスに要求するリソースサービスについて説明します。これは、参照を使用して許可情報を解決する例です。ただし、ステップ4では、リソースサーバーがサブジェクト（UserXYなど）を検証します。これは、認証をトークン自体にエンコードする例です。このハイブリッドアプローチは問題ではありませんが、どちらかを選択することで設計を簡略化できます。
また、トークンサブジェクトUserXYを使用してすべてのユーザーの承認を単一のトークンに付与する代わりに、ここで 最小権限の原則 を使用して、承認サーバーに特定の承認（例： UserXYができることすべてにアクセス権を与えるのではなく、UserXYメールを読んで、UserXYメッセージを作成します。