我正在创建一个基于django-oidc-provider的OpenID Connect（OIDC）提供程序 . 我一直在阅读OpenID Connect规范，我无法弄清楚访问令牌对于某个应用程序是如何独特的 .
请考虑以下与用户Bob的示例：
Bob想要登录到应用程序A，因此他转到其界面并被重定向到OIDC Provider . 身份验证后，他将ID令牌和访问令牌重定向（隐式流）回应用程序A.然后，他使用访问令牌在“/ image / 1”处向A的API发出请求 . API使用访问令牌联系OIDC提供程序以将用户的身份声明为Bob . 然后，API返回用户Bob的“/ image / 1”数据，假设信息存在 . 对于任何后续请求，Bob继续将其访问令牌发送到A的API .
然后，Bob决定他想要访问应用程序B的API . 他向B的API发送了与A的API一样的访问令牌 . B的API通过令牌传递给OIDC Provider，并将用户的身份声明为Bob . B的API然后返回Bob的请求信息 .
是什么阻止了这种情况发生？我看到至少有两种可能的解决方案：
-
当到达Google's token validation endpoint时，返回"aud"参数 . 应用程序B 's API would have to check this parameter to decide that the token is not valid for it'自己的API？
-
在请求特定于资源提供者的令牌时，必须添加其他范围"app-A-api" . 然后，当API验证令牌时，API将确保令牌包含所需的范围 .
以下哪种方法或其他方法符合OIDC规范？如果应该使用上述其中一个，我是否正确假设我应该添加一个返回范围或aud的新/ tokeninfo endpoints ，而不是将该信息添加到/ userinfo endpoints 返回的信息中？
任何输入都表示赞赏 . 我认为我的很多困惑来自于没有看到“范围”参数被用于在任何OIDC示例中委托对资源提供者的访问 .
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 Drive和Google Plus执行其操作，那么app-C将要求其用户提供包含属于Google Cloud 端硬盘和Google Plus的范围的访问令牌 . 它只是一个令牌，两个Google API都会接受它 .
关于tokeninfo endpoints ，它有自己的RFC，名为OAuth 2.0 Token Introspection，因此您可以检查它 .