Защита связи между внутренними микросервисами с использованием JWT

Question

скажем, у нас много микросервисов в бэкэнде. Существует служба API шлюза, которая разрешает пользователю выполнять некоторые действия, выполняемые в пользовательском интерфейсе. Затем микросервис (MicroBackend1) вызывает следующий микросервис (MicroBackend2), а следующий вызывает следующий. Какой JWT следует передать для авторизации между MicroBackend1 и MicroBackend2? Какой подход мне подходит:

1. JWT от пользователя пользовательского интерфейса передается только первому MicroBackend1. Затем он передал свой собственный JWT MicroBackend2. Контекст знает контекст пользователя, что выполненное действие в пользовательском интерфейсе недоступно в MicroBackend2.

2. MicroBackend1 выполняет запрос токена ActAs к STS, а затем передает новый JWT в MicroBackend2. Это означает, что пользовательский контекст известен MicroBackend2.

3. MicroBackend1 напрямую передает JWT, который он получил от пользовательского интерфейса, в MicroBackend2, поэтому он имеет контекст пользователя.

Каковы плюсы и минусы таких решений? Какой из них вы пробовали, и какой мы должны выбрать?

Answer 1

Третий подход делает работу и решает проблему без лишних усилий.

Второй подход не рекомендуется, поскольку он приведет к трафику доступа к вашей службе токенов и, следовательно, увеличит время отклика.

Однако правила области видимости JWT требуют, чтобы каждый микросервис создавал свой собственный токен для связи с любым другим микросервисом. Это имеет преимущество в виде более безопасных микросервисов и более высокого уровня отслеживания, но сопряжено с дополнительными затратами на сложную инфраструктуру открытых ключей и дополнительной обработкой при создании самого нового JWT.

В конце концов ваши требования безопасности и SLA «запрос-ответ» решат, какой подход поддерживает баланс между ними и наиболее близок к решению ваших требований.

Answer 2

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

Однако до этого я использовал для получения токена JWT из пользовательского интерфейса, и он был проверен нашим уровнем узла (BFF) и, в свою очередь, обменивался на то, что мы использовали для вызова токена доступа к узлу. По сути, у нас есть пользователь на уровне узла, для которого мы использовали этот токен и генерировали его. Этот токен имеет авторизацию практически для всего (что происходило постепенно, и в итоге мы отказываемся от авторизации для последующих сервисов) Это помогло нам, потому что мы могли гарантировать, что маркер доступа пользователя мало используется для наших нисходящих сервисов, и если будет сделан вызов для нисходящего потока непосредственно с токеном пользователя, он будет отброшен. Недостатком создания нашего собственного токена было то, что мы в конечном итоге предоставили доступ ко всем службам и всем API-интерфейсам этого токена.

Если вы передадите токен из пользовательского интерфейса в нисходящий поток, то плюсы и минусы несколько перевернуты. Также предоставление правильных ролей пользователю становится затруднительным.