REST и сервис для сервисной аутентификации

Question

Я работаю над микросервисным приложением и сейчас думаю о том, как обращаться с безопасностью при обращении в службу.

Для простоты представьте, что у меня есть только две службы:

1. Api-шлюз (для доступа к inte rnet)
2. Служба A (в DMZ, доступна только через API gtw)

Служба A имеет конечную точку POST, скажем, POST /customers для создания клиента.

У меня также есть конечная точка POST на Api Gateway POST /gtw/customers. Это работает таким образом, что он выполняет некоторую проверку (вызывает другую службу), и если все в порядке, то он делегирует запрос в службу А.

Чего я хочу добиться, так это того, что конечная точка в службе А может быть вызывается только шлюзом API (поэтому проверка применяется). Я рассматриваю два подхода:

1. Защитите конечную точку в Сервисе A токеном JWT, и шлюз API сгенерирует токен и затем может вызвать конечную точку в Сервисе A
2. Оставьте это как это потому, что служба A работает в демилитаризованной зоне, поэтому ее нельзя вызывать напрямую (поэтому в основном она защищена на уровне «инфраструктуры»).

Является ли это хорошим подходом для обработки аутентификации между сервисами и сервисами? по токенам JWT?

Answer 1

Насколько я знаю, я бы предложил вам использовать OAuth для обеспечения аутентификации между сервисами. Для вашего конкретного случая c вы можете использовать тип предоставления учетных данных клиента. Это довольно легко реализовать. Использование JWT - один из способов сделать это, но для вашего случая я считаю, что OAuth 2.0 с клиентскими учетными данными был бы идеальным выбором.

Answer 2

Давайте обсудим оба варианта

Защита конечной точки в Сервисе A токеном JWT, и шлюз API сгенерирует токен, а затем сможет вызвать конечную точку в Сервисе A

Аутентификация иногда не единственная вещь. Авторизация также играет большую роль. Если ваш сервис имеет функциональность, основанную на ролях, такой подход необходим. Ваш шлюз будет аутентифицировать токен и передаст вам тот же токен. JWT будет содержать заявки, которые также могут включать роли. Таким образом, вы должны повторно проверить и извлечь заявки, прежде чем полностью заполнить запрос в зависимости от роли. Даже при межсервисном обмене данными службы должны передавать маркер JWT вместе с запросом, и ваша служба должна проверять его. Я всегда предпочитаю этот подход, так как JWT всегда может быть проверен локально, и вы можете избежать обхода Http, поэтому он не замедляет поток.

Оставьте его как есть, потому что служба A работает в DMZ, поэтому он не может быть вызван напрямую (поэтому в основном он защищен на уровне «инфраструктуры»

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