使用 JWT 进行模拟答案

【问题标题】：Impersonation using JWT使用 JWT 进行模拟
【发布时间】：2017-06-04 12:01:43
【问题描述】：

我正在尝试基于此article 实现 JWT 授权。我还需要让特定用户（管理员）冒充其他用户（客户）。

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

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

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

【问题讨论】：

stackoverflow.com/questions/22512794/…

标签： asp.net oauth-2.0 jwt

【解决方案1】：

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

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

在JWT RFC 中没有为此目的定义任何特定声明。在这个draft 中，作者建议包含一个代表声明obo

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

prn 标识 JWT 持有者所代表的委托人。
ctx 建立允许持有者代表委托人行事的许可上下文。此声明应强制限制行使授权的上下文

请注意，obo 声明不包含在 IANA's JSON Web Token Claims 中，因此应将其视为建议。 OpenID 中有类似的声明azp，但不清楚如何应用它

azp ：授权方 - ID Token 的发行方

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

【讨论】：

【解决方案2】：

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

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

最终，您可能最终会拥有一个常规 API 端点，但这样的请求除外 ...

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

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

【讨论】：