问题描述
我目前正在实施 OAuth 令牌交换 STS 并且有点挣扎。标准在 https://tools.ietf.org/html/rfc8693 中定义 我的用例涉及由用户（主体）操作触发的一系列系统到系统调用。我想确保端点级别的授权是通过范围和列入白名单的 client_id 的混合来完成的。此外，我想保留客户上下文。
我看到令牌交换场景在这里是有效的。该规范给出了一个示例，其中生成的令牌包含被授权访问的参与者。但是，规范将逻辑系统（又名 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","cid":"3rd_client_that_conducted_token_exchange","act":
{
"cid":"2nd_client_id","act":
{
"cid":"initial_client_id"
}
}
}
我不确定“行为”声明是否有必要的结构（据我所知，没有）。这里有最佳实践吗？好奇你的想法！ :)
解决方法
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 上的资源。