это логика в общем виде:
Когда пользователь входит в систему, BE назначает временный токен для этого имени входа.
Если BE панели мониторинга и приложения app1 отличаются, db-be передает активные токены в app1-be
ИЛИ ЛУЧШЕ будет централизованный BE только для генерации токена сеанса (см. https://www.keycloak.org/ и программное обеспечение для управления идентификацией), где каждый вовлеченный BE ищет активные токены.
Когда пользователь нажимает кнопку на панели инструментов app1, BE перенаправляет его на что-то вроде http://[app1]? token =[hash1234] где токен - значение токена пользователя.
Пользовательский интерфейс приложения app1 запускается, читает токен и сохраняет его в локальном хранилище.
Когда app1 вызывает BE через rest, обычно используя угловой перехватчик, каждый вызов подписывается значением заголовка, таким как {authentication: bearer [token value]}, где токен-носитель - это токен, на котором уже зарегистрирован канал-носитель.
BE проверяет, что токен уже действителен (скорее всего, при обращении к серверу идентификации) и, если это так, предоставляет доступ к вызываемым ресурсам.,
См. Аутентификация JWT и вход в систему единого входа.