Используйте JWT для аутентификации отдельного микросервиса API

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

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

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

Ваш сервер аутентификации должен быть единственным эмитентом JWT для ваших микросервисов. Итак, когда пользователь входит в систему и успешно аутентифицируется, ваш сервер аутентификации выдает JWT, подписанный закрытым ключом (подписание ДОЛЖНО быть асимметричным - RS256 является одним из примеров), который вы сохраняете только на сервере аутентификации; не передавайте этот закрытый ключ другим микросервисам, внутри которых вы хотите проверить JWT. Что вы можете сделать, так это получить открытый ключ на основе закрытого ключа, которым вы подписываете свои токены, и опубликовать его на конечной точке на вашем сервере аутентификации, которая не требует аутентификации — открытый ключ будет представлен в форме ЮВК (см. ссылку на спец). Google делает нечто подобное здесь. Затем в каждом из ваших микросервисов вашей библиотеке нужно будет разработать способ выполнения запроса GET к конечной точке открытого ключа на вашем сервере аутентификации каждые X минут, чтобы увидеть, есть ли какие-либо изменения, и кэшировать открытый ключ в каждом микросервисе. Кэшируя открытый ключ в микрослужбе, вы сможете проверить запрашивающий JWT внутри запрашиваемой службы.

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

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