Использование аутентификации JWT на нескольких микросервисах

Question

У меня есть поиск в Интернете для ответа на этот вопрос, но нет ничего похожего на мои настройки.

Итак, у меня есть одностраничное приложение и 3 службы:

1. Бэкэнд-сервис - сервис A
2. Сервис для обслуживания статических файлов SPA - сервис B
3. Сервис аутентификации - сервис C

Процесс выглядит следующим образом:

• Пользователь заходит на сайт, переходя на / службы B, перенаправляется на /login службы B.
• Пользователь вводит учетные данные, и они отправляютсяслужбе C для выполнения процесса аутентификации и получения разрешений для пользователя эти данные отправляются в JWT.
• Служба B затем помещает их в файл cookie и возвращает их в браузер пользователя.
• Затем пользователь выполняет задачу, для которой требуется JWT, поэтому я должен отправить этот файл cookie в службу A, но есть проблема, я не могу это сделать, файл cookie предназначен только для службы A.

https://auth0.com/docs/security/store-tokens - эта ссылкаПример источника, который я обнаружил, говорит о том, где хранить токены для SPA. Там написано, что я должен использовать cookie для хранения JWT, если:

• Если у меня есть свой собственный бэкэнд
• Если бэкэнд находится в том же домене, что и сам сайт.

Проблема в том, что мой бэкэнд имеет другой URL, это совершенно другой сервис, поэтому использование куки не будет решением, или, по крайней мере, мне так кажется.

Затем он говорит:

Если ваше одностраничное приложение вообще имеет внутренний сервер, то токены должны обрабатываться на стороне сервера с использованием потока кода авторизации, потока кода авторизации с проверочным ключом для обмена кодами (PKCE) или Hybrid Flow.

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

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

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

Спасибо за чтение и помощь!

Answer 1

Одним из решений является отправка запросов в бэкэнд-сервис с помощью JWT в параметре запроса.

После этого в бэкэнд-сервисе может быть промежуточное программное обеспечение, которое преобразует его в заголовок Authorization, чтобы библиотекипосмотри на это продолжай работать.

Answer 2

Таким образом, я решил реализовать это решение, но сначала немного уточнений.

Когда браузер попытается посетить сайт, как указано в вопросе, он будет перенаправлен на маршрут / loginпроверить пользователя. Но если пользователь не существует, то я разрешаю пользователю видеть сайт, но с минимальными разрешениями. Таким образом, если пользователь аутентифицирован, cookie-файл содержит jwt с необходимыми данными. Если пользователь является гостем, служба B все равно вернет cookie, но укажет, что пользователь является гостем.

Я выбрал способ реализации:

• Из-за вышеприведенного объяснения мы всегда получаем файл cookie от службы B, а это значит, что мы всегда можем сказать нашему сайту сохранить его в LocalStorage браузера, поэтому я решил сохранить в нем JWT.
• Для каждого запроса выборки, который я отправляю в службу A, я устанавливаю заголовок с именем Authorization, значение которого будет Bearer <the jwt token> (вставьте jwt внутри <the jwt token>), как указано в этом MDN статья об авторизации.

О безопасности:

Так как сохранение JWT в cookie, связанном со службой A, невозможно (служба B и A принадлежат к разным доменам)Мы остались с опцией LocalStorage. LocalStorage не самый безопасный способ, по умолчанию он уязвим для атак XSS, но, как указано в этом ответе, от mikejones1477, современные браузеры имеют надежную защиту от XSS, а LocalStorage не уязвим для CSRF. ,Поэтому, по сути, следует уделять особое внимание атакам XSS, но именно так стало возможным передавать токен между службами из разных доменов.