Кажется, что в JWT RFC нет проблем со сложными массивами, такими как:
{
"email": "[email protected]",
"businesses": [
{
"businessId": "1",
"businessName": "One",
"roles": [
"admin",
"accountant"
]
},
{
"businessId": "2",
"businessName": "Two",
"roles": [
"support"
]
}
]
}
И это кажется желательным сценарием для наших нужд, поскольку как часть токена мы хотели бы иметь список предприятий, к которым пользователь имеет доступ, и какие роли он выполняет для каждого бизнеса (это часть его идентичности). Политики авторизации в API позже поймут эти группы и применит необходимую логику авторизации.
Я видел, что с IdentityServer4 утверждения добавляются к свойству ProfileDataRequestContext IEnumerable<Claim> IssuedClaims.
Есть ли какая-либо рекомендуемая альтернатива этой сложной структуре претензий? Если нет, есть ли способ построить эту структуру с помощью IdentityServer4 (возможно, какое-то расширение?), Или единственный способ - вручную сериализовать JSON, поскольку утверждение, похоже, принимает только строку?
PS: я видел этот вопрос и этот другой, где один из авторов Identity Server говорит о том, что нечто подобное является антипаттерном. Не уверен, будет ли антипаттерн иметь сложную структуру утверждений или «детали реализации авторизации» в утверждениях.
Любой совет по этому поводу был бы замечательным!
ОБНОВЛЕНИЕ:
Поразмыслив, я согласен, что наличие сложной иерархии требований нежелательно, и я мог бы обойти эту проблему с помощью грязного решения префикса ролей для каждого businessId. Что-то вроде этого:
{
"email": "[email protected]",
"roles": [
"1_admin",
"1_accountant",
"2_support"
],
"businesses": [
"1_One",
"2_Two"
]
}
таким образом я сохраняю простую структуру, а позже, на клиенте или в API, я могу прочитать претензии и узнать, что 1 - это идентификатор компании с именем One, и у нее есть роли admin и account.
Было бы это лучшим решением?
