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是名称为One的业务的ID，并且它具有admin和account角色。
这会是更好的解决方案吗？