JWT中的复杂声明 [英] Complex claims in JWT
问题描述
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.
这是一个更好的解决方案吗?
索赔与身份信息有关-而不是复杂的权限对象".专门的权限服务会给您带来更好的收益，该服务可以根据用户的身份以您想要的任何格式返回您的权限.
我还希望在使用令牌时，您的许可数据不会改变，否则您最终将获得陈旧的数据.
也就是说-声明在.NET中始终是字符串-但您可以通过将ClaimValueType设置为IdentityServerConstants.ClaimValueTypes.Json来将JSON对象序列化到其中.
The JWT RFC does not seem to have any problem containing complex arrays such as:
{
"email": "test@test.com",
"businesses": [
{
"businessId": "1",
"businessName": "One",
"roles": [
"admin",
"accountant"
]
},
{
"businessId": "2",
"businessName": "Two",
"roles": [
"support"
]
}
]
}
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.
I have seen that with IdentityServer4 the claims are added to the ProfileDataRequestContext's IEnumerable<Claim> IssuedClaims property.
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: 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!
UPDATE:
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": "test@test.com",
"roles": [
"1_admin",
"1_accountant",
"2_support"
],
"businesses": [
"1_One",
"2_Two"
]
}
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.
Would this be a better solution?
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.
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屋！
