На этот счет нет двух способов ...

… Потому что их трое.

Вам было поручено создать несколько приложений или микро-интерфейсов React, каждое из которых требует аутентификации через еще одно приложение React, которое отвечает за SSO (единый вход). Приложение аутентификации должно проверить учетные данные пользователя, а затем, если они действительны, выдать JWT (веб-токен JSON) и перенаправить пользователя в другие приложения в вашей маленькой вселенной микро-интерфейсов.

Как передать этот токен (и любую другую информацию, которой вы хотите поделиться) между приложениями, чтобы пользователь мог делать то, что ему разрешено делать в целевом приложении?

  1. То же происхождение: 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, чтобы узнать день рождения той сестры, которую вы все время забываете

…возможности безграничны. БЕСКОНЕЧНЫЙ.