我正致力于创建基于django-oidc-provider的OpenID Connect（OIDC）提供程序。我一直在阅读OpenID Connect规范，我无法弄清楚访问令牌对于某个应用程序是如何独特的。
请考虑以下示例与用户Bob：
Bob希望登录到应用程序A，因此他转到其界面并被重定向到OIDC提供程序。身份验证后，他将ID令牌和访问令牌重定向（隐式流）回应用程序A.然后他在＆＃34; / image / 1＆＃34;处提出请求。使用访问令牌访问A的API。 API使用访问令牌与OIDC Provider联系以断言用户的身份为Bob。然后API返回＆＃34; / image / 1＆＃34;对于用户Bob，假设信息存在。 Bob继续将他的访问令牌发送到A的API以用于任何后续请求。
然后，Bob决定要访问应用程序B的API。他向B＆amp; API发送了与A＆amp; API一起使用的相同访问令牌。 B的API通过令牌与OIDC Provider联系，并将用户的身份声明为Bob。然后B的API返回Bob的请求信息。
是什么阻止了这种情况发生？我看到至少有两种可能的解决方案：
其中哪些方法或其他方法符合OIDC规范？ 如果应该使用上述其中一个，我是否正确假设我应该添加一个返回范围或aud的新/ tokeninfo端点，而不是将该信息添加到/ userinfo端点返回的信息中？
任何输入都表示赞赏。我认为我的很多困惑来自于没有看到＆＃34;范围＆＃34; param用于在任何OIDC示例中委派对资源提供程序的访问。
答案 0 :(得分：1)
我认为您缺少的是应用程序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云端硬盘和Google Plus执行其操作，则app-C会要求其用户提供包含属于Google云端硬盘和Google Plus的范围的访问令牌。它只是一个令牌，两个Google API都会接受它。
关于tokeninfo端点，它有自己的RFC OAuth 2.0 Token Introspection，所以你可以检查它。