Question

JWT RFC似乎没有包含复杂数组的问题，例如：

{
    "email": "test@test.com",
    "businesses": [
        {
            "businessId": "1",
            "businessName": "One",
            "roles": [
                  "admin",
                  "accountant"
            ]
        },
        {
            "businessId": "2",
            "businessName": "Two",
            "roles": [
                  "support"
            ]
        }
     ]
}

对于我们的需求而言，这似乎是一个理想的场景，因为作为令牌的一部分，我们希望拥有一个用户可以访问的业务列表以及他对每个业务有什么角色（它＆＃39;它的一部分身份）。 API的授权策略稍后将理解这些组并应用所需的授权逻辑。

我已经看到，使用IdentityServer4，声明会添加到ProfileDataRequestContext的{{1}}属性中。

这个复杂的索赔结构是否有任何推荐的替代方案？如果没有，有没有办法用IdentityServer4构建该结构（可能是一些扩展？）或唯一的方法是手动序列化JSON，因为Claim似乎只接受一个字符串？

PS：我见过this question和this other，其中一位Identity Server的作者谈到了类似的反模式。不确定反模式是否会有复杂的声明。结构或＆＃34;授权实施细节＆＃34;在索赔中。

对此的任何建议都会很棒！

更新

在给出一些想法之后，我同意拥有复杂的声明层次结构是不可取的，我可以通过为每个businessId添加前缀角色的脏解决方案解决这个问题。像这样：

IEnumerable<Claim> IssuedClaims

通过这种方式，我保留了一个简单的结构，稍后，在客户端或API，我可以阅读声明，并发现{ "email": "test@test.com", "roles": [ "1_admin", "1_accountant", "2_support" ], "businesses": [ "1_One", "2_Two" ] }是名为1的商家的ID，并且它具有角色One和admin。

这会是一个更好的解决方案吗？

Answer 1

声明涉及身份信息 - 而不是复杂的权限＆＃34;对象＆＃34;。使用专用权限服务可以获得更好的效果，该服务可以根据用户的身份以您想要的任何格式返回您的权限。

我也希望你的权限数据在使用令牌时不会改变，否则你最终会得到过时的数据。

那就是说 - 声明在.NET中始终是字符串 - 但您可以通过将didReceiveRemoteNotification设置为ClaimValueType来将JSON对象序列化为它。

JWT的复杂索赔

1 个答案: