JWT 中的复杂声明 [英] Complex claims in JWT

问题描述

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

The JWT RFC does not seem to have any problem containing complex arrays such as:

{
    "email": "[e-mail]",
    "businesses": [
        {
            "businessId": "1",
            "businessName": "One",
            "roles": [
                  "admin",
                  "accountant"
            ]
        },
        {
            "businessId": "2",
            "businessName": "Two",
            "roles": [
                  "support"
            ]
        }
     ]
}

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

And this seems a desirable scenario for our needs, since as part of the token we'd like to have a list of businesses a user has access to and what roles does he have for each business (it's part of its identity). The authorization policies at the API would later understand those groups and apply the required authorization logic.

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

I have seen that with IdentityServer4 the claims are added to the ProfileDataRequestContext's IEnumerable<Claim> IssuedClaims property.

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

Is there any recommended alternative to this complex claim structure? If not, is there any way to build that structure with IdentityServer4 (maybe some extension?) or the only way would be to manually serialize the JSON since the Claim seems to accept only a string?

PS:我看过这个问题和this other Identity Server 的一位作者谈到了类似的反模式.不确定反模式是否会具有复杂的声明结构或授权实现细节"；在声明中.

PS: I have seen this question and this other where one of the authors of Identity Server talks about something similar being an antipattern. Not sure if the antipattern would be to have complex claims' structure or "authorization implementation details" in the claims.

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

Any advice on this would be great!

更新:

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

After giving some thoughts I agree having a complex hierarchy of claims is not desirable and I could go around this problem with a dirty solution of prefixing roles for each businessId. Something like this:

{
    "email": "[e-mail]",
    "roles": [
        "1_admin",
        "1_accountant",
        "2_support"
     ],
     "businesses": [
        "1_One",
        "2_Two" 
     ]
}

这样我保持了一个简单的结构，然后在客户端或 API 上我可以阅读声明并发现 1 是名称为 One，它的角色是 admin 和 account.

that way I keep a simple structure and later on, at the client or API I can read the claims and find out that 1 is the id for the business with name One and it has the roles admin and account.

这会是更好的解决方案吗?

推荐答案

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

Claims are about identity information - and not complex permission "objects". You are far better off with a dedicated permission service that returns your permissions in any format you want based on the identity of the user.

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

I also hope your permission data doesn't change while the token is being used, otherwise you end up with stale data.

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

That said - claims are always strings in .NET - but you can serialize JSON objects into it by setting the ClaimValueType to IdentityServerConstants.ClaimValueTypes.Json.

这篇关于JWT 中的复杂声明的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！