JWT RFC does not seem to have problems with 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 like a desirable scenario for our needs, since as part of the token we would like to have a list of enterprises to which the user has access and what roles he has for each business (this is part of his identity), Authorization policies in the API will later understand these groups and apply the required authorization logic.
I saw that with IdentityServer4, claims are added to the ProfileDataRequestContext IEnumerable<Claim> IssuedClaims .
Is there a recommended alternative to this complex claims structure? If not, is there a way to build this structure using IdentityServer4 (maybe some kind of extension?), Or is the only way to manually serialize JSON, since the claim seems to only accept a string?
PS: I saw this question and this other , where one of the authors of the Identity Server posts about something like this, which is antipattern. I’m not sure that the antipattern will have a complex claims structure or “details of the implementation of authorization” in the claims.
Any advice on this would be great!
UPDATE:
After a few thoughts, I agree that a complex hierarchy of claims is undesirable, and I could solve this problem with a dirty solution for the prefix role for each businessId. Something like that:
{ "email": " test@test.com ", "roles": [ "1_admin", "1_accountant", "2_support" ], "businesses": [ "1_One", "2_Two" ] }
this way I keep a simple structure, and later, with the client or API, I can read the statements and find out that 1 is an identifier for a business named One and has admin and account roles.
Would this be the best solution?