На этот счет нет двух способов ...
… Потому что их трое.
Вам было поручено создать несколько приложений или микро-интерфейсов React, каждое из которых требует аутентификации через еще одно приложение React, которое отвечает за SSO (единый вход). Приложение аутентификации должно проверить учетные данные пользователя, а затем, если они действительны, выдать JWT (веб-токен JSON) и перенаправить пользователя в другие приложения в вашей маленькой вселенной микро-интерфейсов.
Как передать этот токен (и любую другую информацию, которой вы хотите поделиться) между приложениями, чтобы пользователь мог делать то, что ему разрешено делать в целевом приложении?
- То же происхождение: localStorage или sessionStorage
В производственной среде вы обычно обслуживаете все свои приложения из одного источника, что позволяет хранить токен в localStorage. Пока все ваши приложения имеют одно и то же происхождение (например, тот же протокол, порт (если указан) и хост), каждое приложение может получить доступ к токену в вашем браузере window.localStorage (или sessionStorage, если вы хотите, чтобы токены были очищаются при выходе пользователя) и отправляют его вместе с любыми запросами к серверным службам, требующим токенов.
2. Одинаковое происхождение: файлы cookie.
Да, старомодное доброе печенье. Хотя вариант 1, описанный выше, гораздо более популярен, вы можете хранить токен в файле cookie, если он не превышает 4 КБ (максимальный размер файла cookie). Файлы cookie - это текстовые файлы, в которых изначально хранится только идентификатор сеанса пользователя. Все остальное о пользователе хранится на стороне сервера в так называемом сеансе. С JWT вместо того, чтобы запекать идентификатор сеанса в куки, вы запекаете токен в куки. Сервер получает ваш файл cookie и выбирает сеанс пользователя на основе информации, декодированной из токена внутри.
3. Перекрестное происхождение: передайте токен в параметрах URL.
Во время разработки вы часто запускаете приложения React на отдельных серверах разработки веб-пакетов. Поскольку вы не можете запускать несколько приложений на одном сервере разработки, вы назначаете каждому приложению уникальный адрес. Например, AppA получает localhost: 7770, а AppB получает localhost: 5000. Поскольку они имеют разное происхождение, вы не можете сохранить токен из AppA в localStorage AppB. Чтобы передать токены из AppA в AppB, добавьте токен в параметры URL при перенаправлении из AppA в AppB и убедитесь, что в целевом приложении есть способ синтаксического анализа параметров URL для токена.
Для этого пригодится query-string. Вы передаете строку запроса window.location.search (window.location.search возвращает часть строки запроса URL-адреса). query-string затем превращает строку запроса в хэш, из которого вы можете вернуть значение по его ключу.
Пример:
AppA перенаправляет пользователя в AppB, добавляя токен и другую информацию в параметры URL:
window.location.assign(‘localhost:5000/bonkers?token=sometoken&status=hungry’)
Свойство window.location.search указанного выше URL-адреса содержит только строку запроса, которая на самом деле представляет собой что-нибудь после "?":
token=sometoken&status=hungry
AppB использует строку запроса для анализа строки запроса…
const parsed = queryString.parse(window.location.search)
… И превратите строку запроса в хэш, из которого вы можете читать:
console.log(parsed) // output: {token: ‘sometoken’, status: ‘hungry’}
Чтобы получить только токен из параметров URL:
console.log(parsed.token) // output: ‘sometoken’
И теперь ваш AppB может делать с токеном все, что угодно, например
- сохранить его в хранилище LocalStorage или Redux AppB или в собственном состоянии приложения.
- отправьте его вместе с вызовами API для гидратации вашего состояния и инициализации приложения
- расшифруйте его с помощью jwt-decode, чтобы узнать день рождения той сестры, которую вы все время забываете
…возможности безграничны. БЕСКОНЕЧНЫЙ.