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

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

В микросервисах подход с одним секретным ключом быстро ломается. Представьте, другой микросервис получает jwt токен и должен понять, валидна ли подпись. Что делать? Отдать ему тот же секретный ключ? Но в таком случае этот сервис сможет сам выпускать токены. Если таких микросервисов десятки или сотни, шанс утечки секретного ключа очень высок. Как тогда поступить, чтобы другие микросервисы могли проверять валидность токена, но не имели возможности его выпустить?

В одной из компаний, где мы использовали микросервисную архитектуру, я столкнулся с этим вопросом в один из первых дней. И решение здесь простое: вместо классического алгоритма HS256 с одним приватным ключом использовать алгоритм RS256, в котором есть 2 ключа: приватный и публичный. Приватный ключ хранится только на сервисе авторизации и позволяет подписывать токены. Остальные сервисы держат у себя публичный ключ и проверяют подпись без возможности подписывать токены. Даже если публичный ключ кто-то стащит, сам по себе он бесполезен для мошенника — токен всё равно не подделаешь.

Токен настолько публичный, что лежал у нас на сайте по адресу example.com/jwt.key, чтобы все разработчики могли быстро взять его для нового микросервиса 😁

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

Кстати, на собесах удалось раз 5 блеснуть знаниями про RS256, чего собеседующие точно не ожидали))

🔥 – не знал
👍 – знал