Oauth 2.0 如何在OpenID Connect中区分资源提供者之间的访问令牌？

我正在基于以下内容创建OpenID Connect（OIDC）提供程序。我一直在阅读OpenID Connect规范，但我无法理解访问令牌对于特定应用程序是如何唯一的

考虑以下用户Bob的示例：

Bob想登录到应用程序A，因此他转到其接口，并被重定向到OIDC提供程序。身份验证后，他被重定向（隐式流）回应用程序A，并带有ID令牌和访问令牌。然后，他使用访问令牌在“/image/1”向a的API发出请求。API使用访问令牌联系OIDC提供者，以断言用户的身份为Bob。然后，API在“/image/1”处为用户Bob返回数据，假设信息存在。Bob继续将其访问令牌发送到A的API，以用于任何后续请求

然后，Bob决定访问应用程序B的API。他向B的API发送与A的API使用的相同的访问令牌。B的API使用令牌联系OIDC提供者，并断言用户的身份为Bob。然后，B的API为Bob返回请求的信息

是什么阻止了这种情况的发生？我认为至少有两种可能的解决方案：

当接触到“aud”时，返回参数。应用程序B的API必须检查此参数，以确定令牌对其自己的API无效

当请求特定于资源提供者的令牌时，必须添加一个附加作用域，例如“app-A-api”。然后，当API验证令牌时，API将确保令牌包含所需的范围 以下哪些方法或其他方法符合OIDC规范？ 如果应该使用上述任一项，我是否正确地假设应该添加一个新的/tokeninfo端点来返回scope或aud，而不是将该信息添加到/userinfo端点返回的信息中

---

欢迎您的任何意见。在任何OIDC示例中，我认为我的很多困惑都是因为没有看到“scope”参数被用来委托对资源提供者的访问

我认为您缺少的是应用程序A及其API是两个独立的应用程序。因此，令牌是为应用程序A颁发的。如果app-A-api仅将访问令牌用于用户身份验证，那么最好使用ID令牌-它可以在不访问OAuth2服务器的情况下进行验证。在此场景中，app-A-api自行管理其用户权限

如果app-A-api需要令牌来获取其客户端的作用域（权限）列表，则使用访问令牌。但在此场景中，app-A-api（和app-B-api）只是接受访问令牌-他们不是令牌的目标受众（

aud

属性）。应用程序A是令牌的受众

API只是检查访问令牌是否包含与它们相关的作用域。他们信任令牌颁发者，由用户决定是否信任应用程序A代表他们执行操作

例如，如果JavaScript应用程序C（app-C）仅使用Google Drive和Google Plus进行操作，则app-C将要求其用户提供范围属于Google Drive和Google Plus的访问令牌。这将只是一个令牌，两个谷歌API都将接受它

---

关于tokeninfo端点，它有自己的RFC，因此您可以检查它。

有趣的答案。我想指出，令牌的访问群体可能受到授权服务器或客户端配置的限制（1个客户端对应1个RS）。此外，您还可以通过某种方式让客户指示授权请求涉及哪些RS。感谢Florent提供的信息。我不知道ResourceIndicators草案。虽然为了更好地了解它，我不需要基于请求的“Resource”的自定义令牌（如中所述）。那么，在我的两个解决方案中，如果我理解正确的话，最好让API检查授权时额外请求的范围，而不是验证“aud”参数，因为这样可以更容易地撤销令牌，并允许令牌用于多个API？