1

我目前正在实施 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"
    }
  }
}

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

4

1 回答 1

2

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

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

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

你提到你有一个系统链，你想在它们之间交换代币。我相信对于这种情况，客户 ID 确实会成为您act索赔的主题。如果我理解正确，您会遇到这样一种情况，即您有一个用户 X 的令牌，该令牌被颁发用于 API 服务 1（aud声明表明这一点）。然后 API 服务 1 想要获得对服务 2 的访问权限，并且需要交换令牌。它现在获得另一个令牌，其中 sub 是用户 X，受众是服务 2，并且act.sub是服务 1，因为该服务现在充当用户并希望访问服务 2 的资源。

于 2021-02-11T15:44:03.040 回答