0

我正在创建一个基于django-oidc-provider的 OpenID Connect (OIDC) Provider 。我一直在阅读 OpenID Connect Spec，但我无法弄清楚访问令牌对于某个应用程序是如何唯一的。

考虑以下用户 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 请求的信息。

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

  1. 当访问Google 的令牌验证端点时，会返回“aud”参数。应用程序 B 的 API 必须检查此参数以确定令牌对于它自己的 API 无效？
  2. 当请求特定于资源提供者的令牌时，必须添加一个额外的范围，比如“app-A-api”。然后，当 API 验证令牌时，API 将确保令牌包含所需的范围。

哪些方法或其他方法符合 OIDC 规范？如果应该使用上述之一，我是否正确假设我应该添加一个返回范围或 aud 的新 /tokeninfo 端点，而不是将该信息添加到 /userinfo 端点返回的信息中？

任何输入表示赞赏。我认为我的很多困惑来自于在任何 OIDC 示例中没有看到用于委托对资源提供者的访问的“范围”参数。

4

1 回答 1

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 Drive 和 Google Plus 范围的访问令牌。它只是一个令牌，两个 Google API 都会接受它。

关于 tokeninfo 端点，它有自己的 RFC，称为OAuth 2.0 Token Introspection，因此您可以检查它。

于 2017-04-28T07:18:12.197 回答