在使用asp.net核心API后端配置我的IdentityServer4（使用Identity）资源所有者授权流程时，我开始认为为了用户安全性，JWT访问令牌中可能仍然会省略“Name”声明吗？此声明不适用于IS4的开箱即用行为 .
以前，我在IS4 Config.cs文件中添加了访问令牌的“名称”声明，如下所示：
var claims = new List<string>
{
JwtClaimTypes.Name
};
return new List<ApiResource>
{
new ApiResource("api1", "Auth API", claims)
};
我这样做是因为它允许一个简单的方法来获取登录用户的ClaimsPrincipal.Identity.Name，供用户在Controller操作中查找 .
var name = User.Identity.Name;
var user = await _userManager.FindByNameAsync(name);
但是，IS4访问令牌（使用Identity时）包括“Sub”声明中的用户GUID ID . 有了这个，我们还可以使用以下内容查找用户：
var userId = User.Claims.FirstOrDefault(u => u.Type == "sub").Value;
var user = await _userManager.FindByIdAsync(userId);
我知道LINQ查询的处理稍微多一点（几乎没有任何东西），但我认为保护用户可能是值得的's username (email address in my situation) if an access token ever fell into the wrong hands. Especially since JWT'很容易用jwt.io解码 .
你们同意还是不同意？或者我是以错误的方式看待这个并错过了什么？
1 回答
JWT通常包含公共数据，它是独立的 . 即，您无需与后端服务器通信即可构建用户身份 . 您应该使用https防止令牌掉入错误的手中 . 此外，您应该 balancer 令牌有效性窗口（可用性与安全性）并使用nonce来最大化安全性 .
我不认为索赔收集中应该省略'name' . 您正在做的有效用例是，您需要确保对用户存储的更改立即反映在您的Web API中 . 对于自包含令牌，如果更改数据存储中的“名称”，则用户在发出新令牌之前不会看到该更改 . 在这种情况下，使用“引用令牌”可能是一个不错的选择 .
此外，您似乎从Web API直接访问用户存储 . 虽然您可能有正确的推理，但使用基于令牌的身份验证的想法是将身份验证委派给外部方（Identity Server） . 所以常见的模式是
在访问令牌中包含Web API中所需的每个公共数据 .
如果令牌变得太大，请在令牌中包含声明的子集，并在需要时查询用户信息 endpoints .
如果您有正当理由，请使用reference tokens . 但这会影响性能，因为它需要与身份服务器进行反向信道通信 .