使用 JWT 进行模拟

Question

我正在尝试根据这篇文章实现JWT授权。我还需要让特定用户（管理员）冒充其他用户（客户端）。

我在这里看到两种可能性：

• 使用管理令牌发出管理请求，并将模拟的 client_id 添加到每个请求中；
• 为管理员请求一个新令牌，该令牌将在其有效负载中包含客户端的用户名和角色，因此它基本上会成为客户端令牌，但它还有两个额外的字段：“impersonated=true”和“impersonator_admin_id=x” 。

我更喜欢第二个，因为将 .net 内置授权属性与客户端角色一起使用会更容易。但我不确定这是否会带来安全漏洞，或者是否可以使用 .Net 的 OAuthAuthorizationServer 来实际实现。

Answer 1

从您的链接中，首先确定管理员是否冒充用户或代表用户行事。注意，代表!=冒充

• 当 A 保持自己的身份并获得 B 的所有权利时，A 代表B 行事

• 当 A 的所有意图和目的都是B 时，A 就冒充B

JWT RFC中没有为此目的定义任何具体声明。在这份草案中，作者建议加入一项代表索赔obo

{"obo": {
    "prn":"mailto:joe@example.com",
    "ctx":["urn:adatum.com:calendar"]
}}

• prn标识 JWT 持有者所代表的委托人。

• ctx 建立允许持有者代表委托人行事的许可上下文。该主张应强制限制行使委托权利的范围

请注意，这些obo声明未包含在IANA 的 JSON Web 令牌声明中，因此应将其视为建议。OpenID中也有类似的说法azp，但不清楚如何应用

• azp：授权方 - ID Token 的颁发方

回答你的问题，在第一种情况下，我认为你正在谈论代表，所以包括 client_id 和安全上下文。第二种情况是冒充。

Answer 2

冒充总是会带来严重的安全隐患，因为它允许“成为其他人”。

因此，您需要确保通过引入密集的审核日志记录等方式使此状态尽可能可见。此外（为了区分真实登录和模拟登录），您希望能够在 JWT 访问令牌中传输有关此非常特殊状态的信息，例如，通过向模拟用户的配置文件中添加额外的模拟和模拟属性（如您在你的第二点）。

最后你可能会得到一个常规的 API 端点，除了这样的请求......

POST https://YOUR_DOMAIN/users/{user_id}/impersonate
Content-Type:   'application/json'
Authorization:  'Bearer {ACCESS_TOKEN}'
{
  impersonator_id: "IMPERSONATOR_ID"
}

...这将分发特定的模拟令牌，允许“通过用户的眼睛”使用服务。