Стратегия аутентификации между двумя микросервисами node.js

Question

Я планирую сделать простой админ CP.Я разработчик PHP старой школы, где обычно все находится на одном огромном монолитном сервере, и концепция микросервисов не применима.

В моем следующем приложении я хотел бы иметь:

Express UI (Frontend) <----> REST / GraphQL API <-----> сервер БД

Идея состоит в том, чтобы максимально ограничить доступ к БД.Все запросы от пользователей будут отправляться только во внешний интерфейс, и API будет использоваться только для других серверов в моем решении.

Я настрою IP-фильтры между API и БД и, вероятно, между Frontend и API.Но меня беспокоит то, что я хочу, чтобы один админ создал продукт.Хотя этот пользователь будет проходить аутентификацию во внешнем интерфейсе с использованием сессий, мне нужно, чтобы запросы к API тоже были несколько аутентифицированы.Пока не обращая внимания на IP-фильтры, не хочу, чтобы кто-нибудь мог отправлять запросы REST в API.

У меня есть несколько идей, пожалуйста, дайте мне свое мнение:

1. совместное использование экспресс-сессии между API и внешним интерфейсом с использованием mongodb (вероятно, на еще одном сервере) - я вижу проблемы с задержкой

2. размещение службы API на том же сервере, что и внешний интерфейс, и использование redis для совместного использования сеансов -своего рода побеждает цель разделения микросервисов

3. при входе в систему, генерируя jsonwebtoken, который всегда находится между внешним интерфейсом и API для любого пользовательского действия - кража cookie будет проблемой, так как я могу только проверить пользователявошел в систему, но он не разрешил выполнение определенного действия

4. при входе в систему, отправив закрытый ключ администратору и заставив его подписать все запросы, отправленные в API - это похоже на перегрузку процессора

---

Есть ли какое-либо общеупотребительное решение, которое мне не хватает?Является ли разделение внешнего интерфейса и API избыточным, или это хорошая практика?Я мог бы легко объединить 2 и общаться с БД напрямую из внешнего интерфейса, а затем я могу управлять всем с помощью сессий, как с PHP.

Спасибо за любые входные данные!Приветствия

Answer 1

Более сложной реализацией (1) является использование сервера сеансов. Идея состоит в том, чтобы просто устранить задержку поиска в базе данных, но не узкое место поиска сеанса в целом. Он действует как слой кэширования. Нулевая реализация кода должна использовать что-то вроде redis или memcache в качестве хранилища сессии.

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

Ключевая идея JWT заключается в том, что вся безопасность скрыта в бэкэнде. Внешний интерфейс только возвращает токен серверу в качестве доказательства аутентификации.

Но так как интерфейс хранит токен, он может быть взломан javascript. Одним из решений является использование файлов cookie HttpOnly в качестве механизма передачи токенов. Я даже видел реализации, в которых основная часть токена отправляется в заголовке Authorization, а подпись отправляется в файле cookie HttpOnly. Это не позволяет сценариям читать весь токен.