Сообщить об ошибкеКороткий ответ
Выбор зависит от того, что важнее для конкретной системы — простота масштабирования без разделяемого состояния (JWT), возможность мгновенного отзыва доступа и единая точка контроля (серверные сессии), или защита самого межсервисного взаимодействия от скомпрометированной сети (mTLS); на практике для внешних клиентов и внутреннего трафика часто используют разные механизмы одновременно.
Как это работает подробнее
Stateless JWT проверяется каждым сервисом локально по подписи без обращения к центральному хранилищу, что снижает задержку, но отзыв конкретного токена до истечения срока требует дополнительного механизма. Серверные сессии требуют обращения к общему хранилищу (Redis/БД) при каждой проверке, добавляя задержку и точку отказа, зато отзыв происходит мгновенно. mTLS защищает сам канал и подтверждает личность сервиса-отправителя, но не заменяет аутентификацию конечного пользователя и требует инфраструктуры выпуска/ротации сертификатов.
- Компромисс. Stateless JWT даёт низкую задержку и независимость от доступности центрального сервиса, но усложняет немедленный отзыв доступа и увеличивает риск при утечке долгоживущего токена; серверные сессии дают мгновенный контроль ценой дополнительной задержки и единой точки отказа; выбор зависит от требований к скорости отзыва доступа (регуляторные требования), ожидаемой нагрузки на сервис сессий и готовности команды поддерживать инфраструктуру PKI для mTLS.
Пример кода
Сценарий: пользователь аутентифицируется один раз -> получает short-lived JWT.
Gateway проверяет подпись JWT и пробрасывает запрос дальше.
Между внутренними сервисами (service A -> service B) трафик поверх mTLS:
сертификат сервиса A подтверждает, что запрос пришёл именно от сервиса A,
даже если сеть между подами потенциально доступна другим нагрузкам в кластере.
Отзыв доступа пользователя -> инвалидация refresh-токена, JWT доживает свой короткий TTL.Что использовать на практике
- Практика. Внешним клиентам обычно выдают короткоживущий JWT (access token) плюс серверный refresh-токен, что сочетает низкую задержку для частых запросов и возможность отзыва через инвалидацию refresh-токена; между внутренними сервисами поверх уже аутентифицированного пользовательского запроса добавляют mTLS или service mesh для защиты от бокового перемещения при компрометации одного сервиса.
Подводные камни
- Риск. Выбирают JWT «потому что модно и не требует состояния», не продумав сценарий компрометации токена, требующий немедленного отзыва; внедряют mTLS как единственный механизм авторизации, подменяя им проверку личности конечного пользователя; недооценивают операционную сложность ротации сертификатов при mTLS в быстрорастущей системе.