9

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

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

这似乎是满足我们需求的理想方案，因为作为令牌的一部分，我们希望有一个用户可以访问的企业列表以及他对每个企业的角色（这是其身份的一部分）。API 的授权策略稍后会理解这些组并应用所需的授权逻辑。

我已经看到使用 IdentityServer4 将声明添加到ProfileDataRequestContext'IEnumerable<Claim> IssuedClaims属性中。

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

PS：我已经看到了这个问题和另一个问题，其中 Identity Server 的一位作者谈到了类似的反模式。不确定反模式是否会在声明中具有复杂的声明结构或“授权实现细节”。

任何关于这方面的建议都会很棒！

更新：

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

{
    "email": "test@test.com",
    "roles": [
        "1_admin",
        "1_accountant",
        "2_support"
     ],
     "businesses": [
        "1_One",
        "2_Two" 
     ]
}

这样我就保持了一个简单的结构，然后在客户端或 API 上，我可以阅读声明并找出1具有名称的业务的 idOne并且它具有角色admin和account.

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

4

1 回答 1

14

声明是关于身份信息的——而不是复杂的权限“对象”。使用专门的权限服务会更好，该服务会根据用户的身份以您想要的任何格式返回您的权限。

我也希望在使用令牌时您的权限数据不会更改，否则您最终会得到陈旧的数据。

也就是说 - 声明始终是 .NET 中的字符串 - 但您可以通过将 JSON 对象设置ClaimValueType为IdentityServerConstants.ClaimValueTypes.Json.

于 2016-09-08T04:56:52.683 回答