Должен ли каждый микросервис управлять своими собственными разрешениями и ролями пользователей?

Это зависит от сложности настройки разрешений.

Если ваши разрешения очень простые, то есть все службы нуждаются в аутентификации и имеют одну роль для работы, вы можете добавить ее в api шлюза.

Если вам нужен более детальный подход, вам нужно сделать это на уровне модуля. Обычно в архитектуре микросервисов каждая служба будет вызывать другую службу, и наличие настроек авторизации на уровне модуля позволяет избежать предварительного знания необходимых разрешений, необходимых в API шлюза. И вы можете развернуть каждый из этих модулей, не задумываясь о других сервисах, иметь детальные разрешения на уровне методов и т. д.

Я работал со следующей установкой, и она сработала очень хорошо:

Процесс входа в систему:

1. Свежий браузер делает запрос на конкретный ресурс
2. Служба шлюза обнаруживает отсутствие файла cookie jwt и перенаправляет на форму входа
3. Форма входа связывается с сервисом авторизации через шлюз. Шлюз разрешает не-jwt звонки только на сервис авторизации
4. Служба аутентификации предоставляет форме входа в систему только что созданный файл cookie jwt и перенаправляет на исходный URL

Нормальная операция:

1. Браузер запрашивает ресурс вместе с файлом cookie jwt
2. Служба шлюза перехватывает запрос и перенаправляет jwt в службу аутентификации для проверки
3. Служба аутентификации проверяет подпись, затем метку времени, затем черный список и возвращает положительный или отрицательный результат
4. Если положительно, служба шлюза перенаправляет запрос в соответствующую внутреннюю службу, в противном случае перенаправляет на вход в систему.
5. Серверная служба не выполняет проверку jwt - она ​​просто доверяет шлюзу отправлять только действительные запросы.
6. Серверная служба проверяет наличие ролей / разрешений / прав, определенных в jwt

Процесс выхода:

1. Браузер делает запрос к сервису авторизации / выходу из системы
2. Служба аутентификации помещает jwt в черный список и перенаправляет на форму входа

Теперь это простой рабочий процесс, который мы реализовали без любой (много) сторонней помощи. В какой-то момент нам пришлось использовать файлы cookie сеанса, но это было по другим причинам. Обратите внимание, что система почти не имеет состояния, за исключением черного списка в службе аутентификации. Невозможно просто выйти из системы с помощью jwt! У нас был РЕДИС для управления черными списками. Вы можете реализовать выход с помощью сеансовых файлов cookie на шлюзе или в службе аутентификации.

Большинство серверных сервисов ожидали своего собственного набора ролей / привилегий / полномочий в jwt. Роли были предоставлены пользователю службой аутентификации и были записаны в предоставленном jwt. Если пользователю была предоставлена ​​новая роль, пользователь должен был выйти из системы / войти в систему, чтобы отразить эту привилегию. Если какая-то привилегия была удалена, то пользователь должен был принудительно выйти из системы - именно здесь играл REDIS.