Ну, я нигде не нашел никаких указаний по этому вопросу, так что вот мой случай.
Я начинаю создавать платформу API, и она основана на токенах JWT, сгенерированных сервером IdentityServer4. И я ожидаю иметь как минимум 75-100 API.
Пытаясь следовать спецификации, мне пришлось бы создать 75 объектов ApiResource и каждый с набором областей (разрешений), поэтому мы будем говорить о 300+ областей. Определение этого в файл, хотя и громоздко, но выполнимо.
Теперь, когда мы go обращаемся к рабочему процессу пользователя, клиент (веб-приложение) теоретически должен будет запросить все утверждения любого пользователя может потребоваться (например, 150 областей), поэтому это очень большой запрос. И если у пользователя много связанных ролей (admin, user, sysadmin), то токен потенциально может содержать все эти области, очень большой токен, который может быть проблематичным c.
Как бы вы рекомендуете это решить? Я вижу несколько вариантов:
- Больше использовать пользовательскую конечную точку с ударом в производительности и стабильности. Таким образом, токен будет меньше, но в конечном итоге мне все равно придется вызывать сервер OID C, чтобы получить больше информации о пользователе.
- Сократить количество областей до одной на Api, но в конце концов это может будет 75 Apis, так что это все еще большое число.
- Уменьшите количество областей до 1-5 для всех Apis, так что это больше группа, чем один API. Это приводит к снижению эффективности в области безопасности (или действительно ли это будет адский ад, чтобы все было сопоставлено и настроено?).