在系统上下文中交换代币后 "act" 声明的形状

Question

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

我看到令牌交换方案在这里有效。该规范给出了一个示例，其中生成的令牌包含被委托访问的参与者。然而，规范将逻辑系统（又名 OAuth 客户端）放入嵌套参与者信息的“子”声明中，如下所示：

{
  "aud":"https://service26.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904100,
  "nbf":1443904000,
  "sub":"user@example.com",
  "act":
  {
    "sub":"https://service16.example.com",
    "act":
    {
      "sub":"https://service77.example.com"
    }
  }
}

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

{
  "aud":"https://service26.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904100,
  "nbf":1443904000,
  "sub":"user@example.com",
  "cid":"3rd_client_that_conducted_token_exchange",
  "act":
  {
    "cid":"2nd_client_id",
    "act":
    {
      "cid":"initial_client_id"
    }
  }
}

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

Answer 1

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

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

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

您提到您有一个系统链，您希望在这些系统之间交换令牌。我相信对于这种情况，客户端 ID 确实会成为您 act 声明的主题。如果我理解正确的话，你有这样一种情况，你有一个用户 X 的令牌，该令牌用于 API 服务 1（aud 声明表明了这一点）。那么API服务1想要访问服务2，需要交换token。它现在获得另一个标记，其中 sub 是用户 X，受众是服务 2，act.sub 是服务 1，因为此服务现在充当用户并希望访问服务 2 的资源。

在系统上下文中交换代币后 "act" 声明的形状

Shape of the "act" claim after token exchange in a system context

oauth-2.0

oauth

clientid

token-exchange