oauth-2.0 - 系统上下文中 token 交换后 "act"声明的形状

Question

我目前正在实现 OAuth token 交换 STS，但有点挣扎。该标准定义于 https://www.rfc-editor.org/rfc/rfc8693 我的用例涉及一系列系统到系统的调用，由用户(主体)操作触发。我想确保端点级别的授权是通过范围和白名单 client_ids 的组合来完成的。此外，我想保留客户背景。

我发现 token 交换场景在这里是有效的。该规范给出了一个示例，其中生成的 token 包含被委托(delegate)访问的参与者。但是，该规范将逻辑系统(又名 OAuth 客户端)放入嵌套参与者信息的“子”声明中，如下所示:

{
  "aud":"https://service26.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904100,
  "nbf":1443904000,
  "sub":"<a href="https://stackoverflow.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="f287819780b2978a939f829e97dc919d9f" rel="noreferrer noopener nofollow">[email protected]</a>",
  "act":
  {
    "sub":"https://service16.example.com",
    "act":
    {
      "sub":"https://service77.example.com"
    }
  }
}

我觉得这有点奇怪。如果参与者 token 也是个性化 token (例如“adminuser”)，我希望“sub”声明能够携带实际主题。在我看来，进行 token 交换的系统将发送 client_credentials token 作为参与者 token 。这不包含“sub”声明，而仅包含“cid”(client_id) 声明。此声明应包含在生成的 token 的“act”声明中，因此我希望生成的 token 如下所示:

{
  "aud":"https://service26.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904100,
  "nbf":1443904000,
  "sub":"<a href="https://stackoverflow.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="d7a2a4b2a597b2afb6baa7bbb2f9b4b8ba" rel="noreferrer noopener nofollow">[email protected]</a>",
  "cid":"3rd_client_that_conducted_token_exchange",
  "act":
  {
    "cid":"2nd_client_id",
    "act":
    {
      "cid":"initial_client_id"
    }
  }
}

我不确定“行为”声明是否有必需的结构(据我所知，没有)。这里有可以遵循的最佳实践吗？好奇你的想法! :)

Answer 1

act 声明没有标准化的结构，RFC 唯一提到的是它应该包含任何可以让您识别参与者的信息。

act 声明是否应包含有关用户或客户端的信息取决于您的系统架构，以及哪些信息可供您的其他服务使用或需要。如果您的场景是将用户的权限委托(delegate)给管理员，并且您希望在 token 中包含该信息，则可以将管理员的数据放入 act.sub宣称。但是，如果您想指出一个客户端正在将权限委托(delegate)给另一客户端，则您将在 act.sub 声明中获得客户端 ID。如果委托(delegate)是在客户端而不是用户之间完成的，则客户端 ID 也可以是主题。

请记住，您还可以使用模拟场景来进行 token 交换。因此，在生成的 token 中，您将不会获得有关 Actor 的任何信息。例如。您可以让您的管理员冒充用户。执行 token 交换后，您将颁发用户的 token ，但没有任何信息表明处理该 token 的实际上是管理员用户。

您提到您有一系列系统，您希望在这些系统之间交换代币。我相信，在这种情况下，客户端 ID 确实会成为您的 act 声明的主题。如果我理解正确的话，您会遇到这样的情况:您拥有用户 X 的 token ，该 token 被颁发用于 API 服务 1(aud 声明表明了这一点)。那么API服务1想要访问服务2，需要交换token。它现在获得另一个 token ，其中 sub 是用户 X，受众是服务 2，act.sub 是服务 1，因为该服务现在充当用户并希望访问服务 2 上的资源。