Аутентификация JWT в архитектуре микросервиса

Question

Аутентификация JWT в архитектуре микросервиса

Вопрос

Вопрос: как можно создать службу аутентификации в приложении микросервиса, чтобы другие службы проверяли этот токен (JWT) и извлекали пользователя?

Возможное решение

Мое текущее мышление основано на вставке аутентификации службы { token, user } в Redis после аутентификации пользователя. Все остальные сервисы могут проверять против пользователя Authorization: Bearer kdI8$dj$nD&... токен заголовка в Redis.

Если token присутствует в Redis, пользователь аутентифицирован.
Если token отсутствует в Redis, пользователь не аутентифицирован.

Пользователь отправляет { username, password } авторизовать сервис
Служба аутентификации проверяет подлинность учетных данных и получает { token, user }
Аутсервисные вставки { token, user } в Redis
Пользователь делает запрос на Service-1 с { token }
Service-1 петли для { token } в Redis и получает { token, user }
Service-1 делает свое дело и отправляет обратно { data }

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

2

authentication microservices node.js php rest

Решение

Другие решения

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

Токен доступа может иметь время истечения, что потребует использования токена обновления для получения нового токена доступа от службы аутентификации:

Когда срок действия маркера доступа истечет, вы вернете клиенту номер 401 из службы X, с которой вы пытаетесь установить связь.
Клиент должен был бы вызвать службу аутентификации, предоставив токен обновления, получив новый токен доступа
- Наконец, клиент снова будет использовать Service X с этим новым токеном доступа, проверит его и получит ожидаемый ответ от Service X.

В моем недавнее назначение Я написал микро-сервис, который проксировал все запросы, проверяя их токены, прокси обрабатывал все, начиная от логина / аутентификации и заканчивая ролями, отправляя 401 для токенов с истекшим сроком действия и отзывая токены обновления и т. Д. Я думаю, что это дало мне большее разделение интересов, чем необходимость иметь дело с токенами во всех сервисах. Однако это, конечно, делает прокси возможным «узким местом» в системе, и в моем случае это нужно для автоматического масштабирования службы аутентификации.

Также я не использовал redis, но хранил хешированный ключ (состоящий из хэшированных свойств accesstoken + salt) в accesstoken, который я мог проверить, перефразируя другие свойства accesstoken + salt.

Важная заметка: В приведенном выше сценарии обновления токена мой прокси-сервер будет испытывать нагрузку только для недействительного / просроченного маркера доступа, хотя в вашем сценарии любая служба может быть доступна с недействительными токенами, я не знаю, имеет ли это какое-либо значение в вашем конкретном случае, но это наверное стоит упомянуть …

Другой подход заключается в том, чтобы позволить Service-A и Service-B вызывать службу аутентификации для проверки токенов, но это будет означать, что между службами будет происходить гораздо больший трафик, поскольку каждый HTTP-запрос с токеном должен быть проверен. В этом случае также неверный запрос токена достигнет вашего Service X и, следовательно, определит некоторую нагрузку на него …

1

Источник

Accepted Answer

Не совсем понятно, почему вы хотите хранить токены в Redis. Маркер безопасности обычно уже содержит информацию о пользователе (данные о претензиях). Если вам нужна информация о пользователе, которая не хранится в токене, вы сможете найти ее с помощью простого запроса к базе данных в заявке на идентификатор пользователя.

Каждый сервис может проверить входящий токен, проверив его цифровой подписи (для этого нужен только открытый ключ сертификата подписи), время жизни (когда истекает токен), аудитория (для которой токен) и т. д. Если вызывающий абонент предоставляет действительный токен, пользователь проходит проверку подлинности.

3