OAuth-リソースサーバーは、アクセストークンが他のリソースサーバーのものではないことをどのように検証しますか？
2つのリソースサーバー-RS1とRS2があり、1つの承認サーバー-ASがある例を考えてみましょう。
RS1とRS2の両方のリソースサーバーが承認サーバーを使用-AS
クライアントがRS1のアクセストークンをリクエストしてRS2に渡す場合、RS2はそれをどのように検証して失敗しますか？
1つの可能性はスコープチェックに依存することですが、スコープチェックは文字列比較にすぎないようです（またはここで私は間違っていますか？）。その場合、RS1とRS2の両方がまったく同じスコープ名を定義している場合（例：Read）、スコープを使用しても信頼性はありません。
JSON Web Token（JWT）（ https://tools.ietf.org/html/rfc752 ）を使用することもできます。
JWTには、発行されたトークンの対象ユーザーを指定するための「aud」パラメーターが含まれています。リソースサービスは、トークンの署名とトークンに含まれるデータを確認する必要があります。
https://tools.ietf.org/html/rfc7523#section- を参照してください
別の解決策は、新しいプロパティを作成することにより、リソースサーバーをアクセストークンに関連付けることです（承認された「リソースサーバー」を識別するための名前またはURLまたはclient_idを含む）。次に、このパラメーターのチェックは、許可サーバーとリソースサーバー間の通信がどのように機能するかによって異なります。
スコープになんらかの名前空間を追加できます。 RS1の場合、スコープの先頭には「RS1 ::」が付けられ、RS2の場合、スコープの先頭には「RS2 ::」が付けられます。したがって、両方のリソースサーバーに読み取りのスコープがある場合、RS1のスコープは、RS2の場合は「RS1 :: read」となり、RS2 :: readの場合があります。